Vox Pulveris

Month 2 - Vocabulary List

Mon, 31 Aug 2026 13:10:42 +0000

Nouns

ager, -ī (m.) - field
fīlius, -ī (m.) - son
fīlia, -ae (f.) - daugther
liber, -rī (m.) - book
magister, -rī (m.) - teacher
puer, -ī (m.) - boy
vir, -ī (m.) - man
fluvius, -ī (m.) - river
īnsula, -ae (f.) - island
odium, -ī (n.) - hatred
vīta, -ae (f.) - life
sacrāmentum, -ī (n.) - oath
caelum, -ī (n.) - sky
terra, -ae (f.) - earth
templum -ī (n.) - temple
domina, -ae (f.) - lady of the house, mistress
mēnsa, -ae (f.) - table
cāseus, -ī (m.) - cheese
pōnum, -ī (n.) - fruit
hōra, -ae (f.) - hour
matella, -ae (f.) - chamberpot, toliet
lucerna, -ae (f.) - lantern
māne, indeclinable (n.) - morning

Adjectives

asper, -a, -um - rough
Graecus, -a, -um - Greek
līber, -a, -um - free
miser, -a, -um - miserable
niger, -ra, -rum - black
noster, -ra, -rum - our
pulcher, -ra, -rum - beautiful
Rōmānus, -a, -um - Roman
tener, -a, -um - tender
vester, -ra, -rum - your (pl.)
parvus, -a, -um - small
multus, -a, -um - many
paucus, -a, -um - few
malus, -a, -um - bad
periūrus, -a, -um - sweare falsely, perjured
optimus, -a, -um - best
maximus, -a, -um - greatest
propitius, -a, -um - favourable

Prepositions

ā, ab (Abl.) - from, away from, in respect of
ad (Acc.) - to, for the purpose of
cum (Abl.) - with, (accompaniment)
dē (Abl.) - from, about, for (reason)
ē, ex (Abl.) - out of
sine (Abl.) - without
in (Acc.) - into (in sense of moving into a state)
in (Abl.) - in, on, (in sense of being in a state)
per (Acc.) - through (space/time), by mean of (mean), for sake of (cause)
trāns (Acc.) - across, over

Conjunctions

sī - if
sive - whether (sive … sive … - enumerating alternatives)
aut - or
ut - so that
tunc - then
quoniam - since
sic - therefore
enim - for (explanetory), (in the 2nd/3rd word of the clause)

Adverbs

quoque - also, too
saepe - often
māne, - in the morning

Numerals

quattuor (indeclinable) - four
quīnque (indeclinable) - five
sex (indeclinable) - six
septem (indeclinable) - seven

Verbs

I	II	III	IV	Tran.
cōgitō	cōgitāre	cōgitāvī	cogitātum	think, ponder, consider
dēbeō	dēbēre	dēbuī	dēbitum	to owe, ought, must, should
errō	errāre	errāvī	errātum	to wander, err, go astray
servō	servāre	servāvī	servātum	to preserve, save, keep, guard
cōnservō	cōnsērvāre	cōnservāvī	cōnservātum	to preserve, conserve, maintain
terrō	terrēre	terruī	territum	to frighten, terrify
valeō	valēre	valuī	valitus	be strong, have power, be well
vocō	vocāre	vocāvī	vocātum	to call, to summon
peccō	peccāre	peccāvī	peccātum	to sin, to make mistake (deliberately)
culpō	culpāre	culpāvī	culpātum	to blame
agō	agere	egī	āctum	to drive, to lead
faciō	facere	fēcī	factum	do
neglegō	neglegere	neglēxī	neglēctum	to neglect, ignore
dīligō	dīligere	dīlēxi	dīlēctum	like
sciō	scīre	scīvī	scītum	to know
iūrō	iūrāre	iūrāvī	iūrātum	to swear
periūrō	periūrāre	periūrāvī	periūrātum	to swear falsely
inveniō	invenīre	invenī	inventum	to find, discover, invent
crēdō	crēdere	crēdidī	crēditum	to believe
salūtō	salūtāre	salūtāvī	salūtātum	to greet
accipiō	accipere	accēpī	accēptum	to receive
faenerō	faenerāre	faenrāvī	faenerātum	to lend
cognōscō	cognōscere	cognōvī	cognitum	ro recognize
quaerō	quaerere	quaesīvī	quaesītum	to find, look for, search for
cēnō	cēnāre	cēnāvī	cēnātum	eat for dinner, eat, dine
impōnō	impōnere	imponsuī	impositum	to put in, lay on, impose
praecīdō	praecīdere	praecīdī	praecīsum	to cut, damage
dormiō	dormīre	dormīvī	dormītum	to sleep, alseep

Irregulars

eō, ire, iī/īvī, itum - to go

	Present	Future	Perfect	Imperative Present
1s	eō	ībō	īvī	-
2s	īs	ībis	īvistī	i
3s	īt	ībit	ivit	-
1p	īmus	ībimus	ivimus	-
2p	ītis	ībitis	īvistis	īte
3p	eunt	ībunt	ivērunt	-

hic, haec, hoc - this / these

	Mas.sg.	Fem.sg.	Neu.sg.	Mas.pl.	Fem.pl.	Neu.pl.
Nom	hic	haec	hoc	hī	hae	haec
Voc	-	-	-	-	-	-
Acc	hunc	hanc	hoc	hōs	hās	haec
Gen	huius	huius	huius	hōrum	hārum	hōrum
Dat	huic	huic	huic	hīs	hīs	hīs
Abl	hōc	hāc	hōc	hīs	hīs	hīs

ille, illa, illud - that / those

	Mas.sg.	Fem.sg.	Neu.sg.	Mas.pl.	Fem.pl.	Neu.pl.
Nom	ille	illa	illud	illī	illae	illa
Voc	-	-	-	-	-	-
Acc	illum	illam	illud	illōs	illās	illa
Gen	illīus	illīus	illīus	illōrum	illārum	illōrum
Dat	illī	illī	illī	illīs	illīs	hīs
Abl	illō	illā	illō	illīs	illīs	hīs

ego, tū, nōs, vōs - I, You / We, You

No distinguish between masculine and femnine.

	1s	2s	1p	2p
Nom	ego	tū	nōs	vōs
Voc	-	-	-	-
Acc	mē	tē	nōs	vōs
Gen	meī	tuī	nōstrī	vōstrī
Dat	mīhī	tībī	nōbīs	vōbīs
Abl	mē	tē	nōbīs	vōbīs

is, ea, id, ei, eae, ea - He, She, It / They

	Mas.sg.	Fem.sg.	Neu.sg.	Mas.pl.	Fem.pl.	Neu.pl.
Nom	is	ea	id	eī	eae	ea
Voc	-	-	-	-	-	-
Acc	eum	eam	id	eōs	eās	ea
Gen	ēius	ēius	ēius	eōrum	eārum	eōrum
Dat	eī	eī	eī	eīs	eīs	eīs
Abl	eō	ea	eo	eīs	eīs	eīs

Compound

abeō, conjugate like eō - go away
exeō, conjugate like eō - go out
absum, conjugate like sum - absent
adsum, conjugate like sum - present

Baremetal Host Audit Report

Mon, 31 Aug 2026 13:00:00 +0000

Host Security Audit — `srv*` Machines

Attack-surface and firewall review of the six srv* hosts, derived entirely from the on-host collector reports in host-env-scan/.

Field	Value
Scope	`srv01hv`, `srv02gate`, `srv03mm`, `srv04fs`, `srv05access`, `srv06hv`
Sources	`host-env-scan/hostenv_srv.md` — sections 2–6 plus the raw `fw.`, `net.sysctl` and `svc.*` appendix entries
Corroborating	`audit-report/NETWORK_TOPOLOGY.md` (findings `T-01`…`T-11`), `Designated VLANs.md`
Method	Desk analysis of existing read-only collection. No scanning, no probing, no connection attempts, no configuration changes were performed for this document.
Collection window (UTC)	2026-08-25 23:05 → 2026-08-26 12:35
Finding prefix	`S-xx` (chosen to avoid collision with `F-xx` in `NETWORK_AUDIT_REPORT.md` and `T-xx` in `NETWORK_TOPOLOGY.md`)

Reading rule used throughout. Section 5 (“Exposure Analysis”) of the collector reports is not taken at face value. Every verdict in this document is re-derived from the raw ruleset in the appendix — fw.nft for the firewalld hosts, fw.iptables for the Proxmox hosts — because the collector’s zone parser drops the default zone and therefore mis-reports reachability on two of the six hosts (finding S-15). Where the raw ruleset was not collected the verdict is stated as an assumption, not a fact.

1. Host inventory

Host	Role	OS / kernel	Uptime	VLANs terminated	Host firewall
srv01hv	Proxmox hypervisor (MS-A2)	Debian 13.0 / 6.14.8-2-pve	119d	10, 200, 204, 214, 300, 400, 1024	PVE `iptables` (default DROP)
srv02gate	DNS / DHCP / RADIUS / reverse proxy / UniFi (RPi)	Debian 13.2 / 6.12.47+rpt-rpi-v8	247d	1, 10, 50, 200, 300, 1024	firewalld (nftables)
srv03mm	Media + backup mirror (UGREEN DXP2800)	Debian 12.15 / 6.1.0-52	2h	200	none
srv04fs	Primary file server (PowerEdge T360)	Debian 13.4 / 6.12.86	102d	200, 400	none
srv05access	Choke / access host, monitoring (RPi 5)	Debian 13.6 / 6.12.47+rpt-rpi-2712	23d	10, 200, 1024, 2871	firewalld (nftables)
srv06hv	Proxmox hypervisor (R740xd)	Debian 13.3 / 6.17.9-1-pve	38d	1(nested), 200, 204, 214, 400, 1024	PVE `iptables` (default DROP)

VLAN roles per Designated VLANs.md: 200 main internal, 2871 management (isolated), 10 IoT, 1024 DMZ, 300 secure enclave, 50 guest, 400 network storage, 204 VM interconnect, 214 HV interconnect. VLAN 1 is live but undesignated (T-10).

2. Attack surface: what is actually reachable, per VLAN

Ports below are inbound-reachable after applying the host’s real ruleset. — means the ruleset drops or rejects everything on that interface.

2.1 srv01hv — PVE firewall, verified from `fw.iptables`

PVEFW-HOST-IN ends in -j PVEFW-Drop / -j DROP, so anything not matched is denied. Interface → security group mapping:

Interface	VLAN	Address	Group	Reachable
`vmbr1plc`	200 main	10.1.1.11	`GROUP-management-IN`	22/tcp, 53/tcp+udp, 80/tcp, 443/tcp, 67-68/udp
`hvintra`	214 HV interconnect	10.129.0.2	`GROUP-pve-basic-IN`	22/tcp, 53/tcp+udp, 111/tcp+udp, 443/tcp, 67-68/udp
`vmbr0vm`	204 VM interconnect	10.128.128.20	`GROUP-pve-basic-IN`	as above
`vmbr4nas`	400 storage	10.255.255.7	`GROUP-nas-IN`	22/tcp, 53/tcp+udp, 111/tcp+udp, 2049/tcp+udp, 135+139+445/tcp, 135+137-139+445/udp
`vmbr2iot`	10 IoT	172.17.1.6	`GROUP-dmz-external-IN`	— (explicit DROP)
`vmbr10ext`	1024 DMZ	172.16.1.6	`GROUP-dmz-external-IN`	— (explicit DROP)
`vmbr3sec`	300 enclave	10.10.1.2	no interface rule	only 22, 3128, 8006, 5900-5999, 60000-60050 from sources in ipset `PVEFW-0-management-v4/v6`
`enp3s0`, `eth0p0`	native/untagged	link-local	no interface rule	as `vmbr3sec`

5405/udp (corosync) is source-pinned to 10.129.0.1 (srv06hv). 9100/tcp (node_exporter), 8006/tcp and 3128/tcp are not reachable from any VLAN except via the management ipset. This host is in the best shape of the six.

2.2 srv06hv — same cluster ruleset

Interface	VLAN	Address	Group	Reachable
`vmbr1plc`	200 main	10.1.1.15	`GROUP-management-IN`	22/tcp, 53/tcp+udp, 80/tcp, 443/tcp, 67-68/udp
`vmbr0vm`	204	10.128.128.2	`GROUP-pve-basic-IN`	22/tcp, 53/tcp+udp, 111/tcp+udp, 443/tcp
`hvintra`	214	10.129.0.1	`GROUP-pve-basic-IN`	as above
`vmbr2nas`	400 storage	10.255.255.1	`GROUP-nas-IN`	22, 53, 111, 2049, SMB set (as srv01hv)
`vmbr10ext`	1024 DMZ	172.16.1.3	`GROUP-dmz-external-IN`	—
`docker`, `hvintrav1`, `ens2f0.*`	1 nested in 214	—	no interface rule	management ipset only

5380/tcp (Technitium DNS admin console) and 9100/tcp are bound to all interfaces but permitted nowhere — blocked. Good.

2.3 srv02gate — firewalld, verified from `fw.nft` `filter_IN_public_allow`

The public zone is bound to six interfaces: eth0 (native), eth0.1 (VLAN 1), eth0.10 (IoT), eth0.50 (guest), eth0.200 (main), eth0.300 (secure enclave). Every one of the following is reachable from all six, including the guest and IoT networks:

tcp 22 53 80 443 1812 1813 5380 5671 6789 8080 8443 8444 8843
9100 11443 27117 8880-8882
udp 22 53 67 546(link-local) 1900 3478 5514 10001
+ ICMP and ICMPv6 accepted unconditionally

eth0.1024 (DMZ) is the only interface in a restrictive zone (block, target %%REJECT%%) and is limited to 53/tcp, 53/udp, 67/udp.

Cross-referencing against what is actually listening:

Reachable and listening	Service
22/tcp	sshd
53/tcp+udp, 67/udp, 5380/tcp	Technitium DNS + DHCP + admin web console
80/tcp, 443/tcp	nginx (reverse proxy, 4 vhosts)
1812/1813 udp	FreeRADIUS
9100/tcp	node_exporter
5671, 6789, 8080, 8443, 8444, 8880-8882, 11443, 28082(no), 3478/udp, 5514/udp, 10003/udp(no)	UniFi Network Application in rootless podman (`pasta`)

Allowed but nothing listening	Note
8843/tcp, 27117/tcp, 1900/udp, 22/udp	Dead allowances. 27117 is UniFi’s MongoDB — a rule that will silently expose the controller database the moment that container binds it.

2.4 srv05access — firewalld, zones verified from `fw.active_zones` + `fw.zones_permanent`

Interface	VLAN	Zone	Reachable
`eth0`	native/untagged	`public` (default)	22/tcp, 22/udp, 80/tcp, 443/tcp, 546/udp
`eth0.200`	200 main	`restrict-regular`	22/tcp, 80/tcp, 443/tcp, 9090/tcp
`eth0.10`	10 IoT	`restrict-ssh-only`	22/tcp
`eth0.2871`	2871 management	`restrict-ssh-only`	22/tcp
`eth0.1024`	1024 DMZ	`dmz`	22/tcp

Correctly blocked on every interface: 111 (rpcbind), 3493 (NUT upsd), 9100 (node_exporter), 5353 + ephemeral (avahi). This is the only host in the set with per-VLAN zone differentiation, and it is broadly sound — the residual issues are the DMZ/IoT-facing SSH and the unauthenticated Prometheus.

2.5 srv03mm and srv04fs — no host firewall

firewalld available: no, and the collector version used (1.0.0) captured no nft/iptables output at all, so no ruleset exists to evaluate. The working assumption — consistent with a stock Debian install and with the reports' unknown verdicts — is that every listening socket is reachable from every VLAN the host terminates. On that assumption:

srv03mm — VLAN 200, 10.1.1.12	Service
22/tcp	sshd
111/tcp+udp	rpcbind
139/tcp, 445/tcp	Samba `smbd`
2049/tcp	kernel NFS server
39101, 45867, 48823, 49651, 50083, 53993 /tcp + 6 udp	`rpc.mountd` (ephemeral)
42547, 57497 /tcp + 43339, 48722 /udp	`rpc.statd`
4330/tcp	PCP `pmlogger`
44321/tcp	PCP `pmcd`
44322, 44323 /tcp	PCP `pmproxy` (HTTP/REST metrics API)
8096/tcp, 7359/udp	Jellyfin (plaintext HTTP)
9100/tcp	node_exporter

srv04fs — VLAN 200 (10.1.1.13) and VLAN 400 (10.255.255.9)	Service
22/tcp	sshd
69/udp	TFTP (`tftpd-hpa`)
111/tcp+udp	rpcbind
137/udp, 138/udp	NetBIOS (`nmbd`)
139/tcp, 445/tcp	Samba `smbd` + `winbind`
990/tcp	vsftpd (implicit FTPS)
2049/tcp	kernel NFS server (5 ZFS backup datasets, `/tank/lockbox`)
33709, 34341, 34733, 48295, 50373, 50689 /tcp + 6 udp	`rpc.mountd` (ephemeral)
41299, 52793 /tcp + 35500, 37950 /udp	`rpc.statd`
9100/tcp	node_exporter

3. Findings

ID	Severity	Summary
S-01	High	srv03mm and srv04fs run no host firewall; the entire storage/backup surface is open to VLAN 200 and VLAN 400
S-02	High	srv02gate exposes 27 port ranges — including SSH, the DNS admin console, RADIUS and the UniFi controller — to the guest, IoT and secure-enclave VLANs
S-03	High	srv02gate is a single unpatched host holding the DNS, DHCP, RADIUS and reverse-proxy planes, L2-attached to six VLANs
S-04	Medium	srv05access accepts SSH from the DMZ, IoT and management VLANs and bridges four VLANs, making it the estate’s most attractive pivot
S-05	Medium	Unauthenticated Prometheus (9090) reachable from VLAN 200; node_exporter (9100) reachable from guest/IoT on srv02gate and unfiltered on srv03mm/srv04fs
S-06	Medium	All six hosts accept ICMP redirects, send redirects, do not log martians, and have reverse-path filtering off (or loose)
S-07	Medium	Proxmox cluster firewall contains rules for interfaces that do not exist on the node, and `GROUP-nas-IN` opens SMB/NFS on hosts that serve neither
S-08	Medium	Four guest/container interfaces bypass the Proxmox per-VM firewall bridge, one of them on production VLAN 200
S-09	Medium	The `PVEFW-0-management-v4/v6` ipset gates the most privileged access on both hypervisors (8006, VNC, SPICE, SSH, migration) and its contents were never collected
S-10	Medium	Unauthenticated and legacy file services on srv04fs: TFTP, NetBIOS, FTPS, NFS with `AUTH_SYS`
S-11	Low	Configuration-integrity defects that will alter network/firewall posture on the next reboot
S-12	Low	Hypervisors run nginx, and srv06hv also Technitium DNS + admin console, alongside `pveproxy`
S-13	Low	Xray tunnelling daemons on both cross-VLAN hosts (srv02gate, srv05access)
S-14	Low	Patch cadence: 247d / 119d / 102d uptime; srv03mm still on Debian 12
S-15	Low (tooling)	`collect_host_env.py` drops the default zone from section 4.1, so section 5 reports 36 srv02gate ports as `filtered` when they are reachable

S-01 — No host firewall on srv03mm and srv04fs — High

Both reports state firewalld available: no / firewalld not installed, and neither has any fw.* appendix entry, so no packet filter of any kind is evidenced. srv04fs is the primary file server: it holds tank/backups/pbs, tank/backups/baremetals, tank/backups/lxskypc, tank/archive and tank/lockbox/lxsky, and exports them over NFS and SMB. srv03mm holds the backup-mirror copy of the same data.

Consequences, on VLAN 200 — which every general-purpose host, both hypervisors and every VM on vmbr1plc can reach:

rpcbind (111) is queryable, enumerating NFS, mountd and statd including their randomised high ports. Combined with an unrestricted /etc/exports this is a direct route to the backup datasets; NFSv3/AUTH_SYS trusts whatever UID the client claims.
SMB (139/445) is exposed on both hosts, with nmbd NetBIOS name service on srv04fs. smb.conf was not collected, so share ACLs and the minimum SMB protocol version are unverified.
srv04fs additionally exposes TFTP (69/udp) and vsftpd (990/tcp).
srv03mm exposes the full PCP stack (pmcd 44321, pmproxy 44322/44323, pmlogger 4330). pmproxy is an HTTP API over the host’s performance metrics; pmcd serves metric namespaces to any client its access controls admit.
Jellyfin (8096) is plaintext HTTP with a login form.

srv04fs is worse than srv03mm because it is dual-homed: the same unfiltered socket set is presented on VLAN 400 (10.255.255.9), the storage VLAN, which is also terminated by both hypervisors and by tap interfaces belonging to guest VMs (see S-08). A compromised VM on the storage VLAN reaches the backup server with no host-level filter in front of it.

The evidence gap here is real and should be closed before the finding is treated as settled — see G-01.

S-02 — srv02gate’s `public` zone spans six VLANs including guest and IoT — High

firewall-cmd --get-active-zones shows:

block
interfaces: eth0.1024
public (default)
interfaces: eth0.50 eth0.300 eth0.200 eth0.10 eth0.1 eth0

and nft list ruleset confirms filter_INPUT_POLICIES jumps each of those six interfaces to filter_IN_public, whose _allow chain holds 27 accept rules (section 2.3 above). The DMZ is the only segment that was actually restricted.

The design intent is visible and inverted: someone carefully placed the DMZ into block, then left the guest network, the IoT network and the “secure enclave” in the same permissive zone as the trusted server VLAN. Concretely, a device on the guest Wi-Fi (VLAN 50, 192.168.1.0/24) can reach:

5380/tcp — the Technitium DNS admin console. Full control of the estate’s resolver: rewrite any A record, point nas.home or srv04fs.nas.home at an attacker host, disable DNSSEC, read every query log.
1812/1813 udp — FreeRADIUS. Offline dictionary attack against the shared secret and, depending on EAP configuration, against user credentials; this is the authentication plane for the wireless/wired 802.1X estate.
8080, 8443, 8843, 6789, 11443, 8880-8882, 3478/udp, 5514/udp — the UniFi controller, i.e. the switch and AP management plane, including the device-inform endpoint and the syslog sink.
27117/tcp — permitted for UniFi’s MongoDB. Nothing is bound to it today, which is the only reason it is not an unauthenticated database exposed to the guest network.
22/tcp — sshd, from guest and IoT.
9100/tcp — node_exporter (see S-05).

22/udp and 1900/udp are also permitted and serve no listening service.

S-03 — Single-host concentration of DNS, DHCP, RADIUS and ingress — High

srv02gate is a Raspberry Pi 4 (Cortex-A72, 7.6 GiB) terminating VLANs 1, 10, 50, 200, 300 and 1024 on one 1G link, and it is simultaneously:

the DHCP server for VLANs 10, 50, 200, 300 and 1024 (67/udp bound to 172.17.1.2, 192.168.1.2, 10.1.1.10, 10.10.1.1, 172.16.1.2),
the DNS server for the estate (10.1.1.10 and 172.16.1.2 appear in the resolv.conf of srv01hv, srv04fs, srv05access and srv06hv),
the RADIUS server,
the TLS reverse proxy (nginx, four 443 vhosts),
the network-equipment controller (UniFi).

Compromise of this host — reachable per S-02 from the least trusted segments — yields addressing, name resolution, network-device management and network authentication in one step. net.ipv4.ip_forward is 0, so it is not the router (the TL-SE5226 is, per T-06), but it does not need to route to be catastrophic.

Aggravating: uptime is 247 days on kernel 6.12.47+rpt-rpi-v8, so no kernel update has been applied in roughly eight months. Two default routes are configured (10.1.1.1 via eth0.200, static; 10.0.2.1 via eth0.1, DHCP), with rp_filter=0.

S-04 — srv05access is the estate’s best pivot, and accepts SSH from DMZ and IoT — Medium

srv05access is the deliberate multihomed choke host. Its zoning is the most disciplined of the six, but the residual surface is exactly the dangerous part:

dmz on eth0.1024 permits ssh. A compromised DMZ host gets an SSH brute-force / credential-replay target that sits on VLAN 200 and on the isolated management VLAN 2871.
restrict-ssh-only on eth0.10 gives every IoT device the same target.
public on eth0 (the untagged trunk parent, native VLAN 1) permits 22/tcp, 22/udp, 80, 443. VLAN 1 is undesignated (T-10) and is the native VLAN on every observed access port, which makes this the least controlled of its five attachment points.
Two default routes (10.1.1.3 via eth0.200, 10.0.1.1 via eth0.2871) with rp_filter=0: egress selection is not deterministic and spoofed sources are not rejected.
sshd_config was not collected, so it is unknown whether password authentication or root login are permitted — this materially changes the severity.

The management VLAN 2871 terminates on this host only (T-04), so srv05access is the sole bridge between “isolated management” and everything else.

S-05 — Unauthenticated monitoring surfaces — Medium

Prometheus 9090 on srv05access is explicitly permitted in restrict-regular, i.e. reachable from all of VLAN 200. Prometheus ships with no authentication. Its /targets, /config and /service-discovery endpoints hand an attacker a complete inventory of hosts, scrape endpoints and any credentials embedded in scrape configs; /api/v1/query exposes the metric history.
node_exporter 9100 is bound to all interfaces on all six hosts. It is reachable from guest and IoT on srv02gate (permitted by the prometheus-node-exporter service in public), and unfiltered on srv03mm and srv04fs. node_exporter discloses kernel and distribution version, every filesystem and mount point, NIC inventory, uptime and systemd unit states — a precise, unauthenticated fingerprint for choosing an exploit.
srv03mm’s PCP pmproxy (44322/44323) and pmcd (44321) are the same class of exposure with a wider metric namespace.

Correctly handled by contrast: 9100 is blocked on both hypervisors and on srv05access itself.

S-06 — Kernel network hardening is off estate-wide — Medium

Host	`accept_redirects`	`send_redirects`	`rp_filter`
srv01hv	1	1	2 (loose)
srv02gate	1	1	0
srv03mm	1	1	0
srv04fs	1	1	0
srv05access	1	1	0
srv06hv	1	1	2 (loose)

accept_source_route is correctly 0 everywhere, and ip_forward / ipv6.conf.all.forwarding are 0 everywhere (so none of these hosts routes between the VLANs it terminates — an important, deliberate control worth preserving).

The remaining settings matter most on precisely the hosts that straddle VLANs:

accept_redirects=1 lets any on-link host inject a route into the kernel’s cache with an ICMP redirect. On srv02gate that means an IoT or guest device can redirect the DNS/RADIUS server’s traffic for a given destination through itself. On srv05access, a DMZ host can do the same.
rp_filter=0 on the four non-Proxmox hosts means a packet with a spoofed source is accepted on any interface. On srv04fs, a host on VLAN 200 can send frames claiming a VLAN 400 source and vice versa, defeating any future source-based rule. This is the single change that most cheaply improves the posture, but see the caveat in section 6 — strict mode will break srv02gate and srv05access while they each carry two default routes.
log_martians=0 on all six means none of the above leaves a trace.

S-07 — Proxmox cluster ruleset contains stale interface rules and over-broad groups — Medium

PVEFW-HOST-IN is byte-identical on both nodes (it is generated from the shared /etc/pve), and references four bridges of which each node only has some:

Rule	srv01hv	srv06hv
`-i vmbr2nas -j GROUP-nas-IN`	does not exist	exists (VLAN 400)
`-i vmbr4nas -j GROUP-nas-IN`	exists (VLAN 400)	does not exist
`-i vmbr2iot -j GROUP-dmz-external-IN`	exists (VLAN 10)	does not exist
`-i vmbr10ext -j GROUP-dmz-external-IN`	exists (VLAN 1024)	exists (VLAN 1024)

Dead rules are not themselves a hole, but they mean the intended posture cannot be read off the ruleset, and a future bridge rename silently re-activates them. More importantly srv06hv has no IoT bridge rule at all — if VLAN 10 is ever added to that node it lands in the default path rather than in GROUP-dmz-external-IN.

GROUP-nas-IN permits 111, 2049, 135, 137-139, 445 on the storage VLAN. Neither hypervisor runs an SMB or NFS server — they are NFS/CIFS clients of nas.home. Every SMB entry and the 2049 entry are unnecessary grants. GROUP-management-IN permits 80 and 443 on VLAN 200, which exists only to serve the nginx instance discussed in S-12.

GROUP-pve-basic-IN and GROUP-nas-IN permit 111 but not the ephemeral rpc.statd ports, so NFS lock recovery from the storage VLAN is filtered — an operational inconsistency that suggests the groups were not derived from the actual service set.

S-08 — Guest and container interfaces bypassing the PVE bridge firewall — Medium

Proxmox filters guest traffic only when the tap is placed behind a per-VM fwbr* bridge, because PVEFW-FORWARD matches --physdev-in fwln+. The following are attached directly to a production bridge:

Host	Interface	Bridge	VLAN	Consequence
srv01hv	`tap106i2`	`vmbr4nas`	400 storage	VM 106 NIC unfiltered on the storage VLAN
srv06hv	`tap104i2`	`vmbr2nas`	400 storage	VM 104 NIC unfiltered on the storage VLAN
srv06hv	`tap110i1`	`vmbr1plc`	200 main internal	VM 110 NIC unfiltered on the production VLAN
srv06hv	`ln_docker` / `pr_docker`	`docker` ↔ `hvintrav1`	1 nested in 214	veth pair named outside the `fwln+` pattern, so `PVEFW-FWBR-IN` never inspects it

The last one deserves emphasis. /etc/network/interfaces.d/sdn on srv06hv builds:

docker bridge_ports ln_docker
hvintrav1 bridge_ports ens2f0.214.1 pr_docker

ens2f0.214.1 is VLAN 1 tagged inside VLAN 214 — the QinQ construct flagged as T-10. Anything on the docker bridge therefore has unfiltered layer-2 access to a double-tagged VLAN riding the hypervisor interconnect trunk. Because the veths are not named fwln*, no Proxmox rule applies to that path at any point. iptables-save contains no DOCKER chains and no nat table, so no alternative filter is in place either.

This corroborates and extends T-09, which counted three such interfaces.

S-09 — The most privileged access path on both hypervisors is unverified — Medium

Both nodes end PVEFW-HOST-IN with:

-p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 8006 -j RETURN
-p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 5900:5999 -j RETURN
-p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 3128 -j RETURN
-p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 22 -j RETURN
-p tcp -m set --match-set PVEFW-0-management-v4 src -m tcp --dport 60000:60050 -j RETURN

These are interface-independent: they apply to every VLAN including the DMZ and IoT bridges, whose GROUP-dmz-external-IN DROP is reached earlier only for traffic that the group’s own rules do not mark. The set therefore defines who can reach the Proxmox web UI (8006), the VNC console range (5900-5999), the SPICE proxy (3128), SSH and the live-migration range on both hypervisors.

ipset list / ipset save is not among the collector’s commands, so the set contents are unknown. The single most privileged access control in the estate is undocumented. If the set contains a broad CIDR such as 10.1.0.0/20, the hypervisor web UI is exposed to the whole of VLAN 200.

S-10 — Unauthenticated and legacy file services on srv04fs — Medium

TFTP (69/udp, tftpd-hpa) has no authentication by design. /etc/default/tftpd-hpa was not collected, so the root directory and whether --create/-c (write access) is enabled are unknown. If writable, any host on VLAN 200 or 400 can place files in the TFTP root; if that root is also served over another protocol, this is a file-write primitive. TFTP on a backup server, exposed unfiltered, warrants immediate confirmation.
nmbd (137/138 udp) is NetBIOS name service — the SMBv1-era discovery protocol. It is broadcasting on 10.1.15.255 and 10.255.255.255. Its presence indicates the Samba install has not been modernised; the minimum protocol version in smb.conf should be confirmed as SMB3.
vsftpd on 990/tcp is implicit FTPS. Only 990 is listening (not 21), so cleartext FTP is not offered, but implicit FTPS is deprecated and vsftpd’s configuration (anonymous access, chroot, allowed users) was not collected.
NFS with AUTH_SYS. nfs-idmapd runs but no rpc.gssd — so there is no Kerberos, and client-supplied UIDs are trusted. Access control rests entirely on /etc/exports, which was not collected. srv03mm is in the same position.

S-11 — Configuration-integrity defects — Low

None of these are exploitable as they stand, but each means the audited runtime state and the on-disk state disagree, so the next reboot produces an unaudited posture.

srv06hv /etc/network/interfaces declares esn2f0.400 and esn2f0.1024 — ens transposed to esn. The bridges vmbr2nas and vmbr10ext list ens2f0.400 / ens2f0.1024 as bridge-ports, which are never declared. The storage and DMZ bridges depend on interfaces that the config file does not create. It also declares nic1 / nic1.200 for a NIC that is down.
srv01hv vmbr3sec is declared inet dhcp and carries a static address 10.128.255.1/24; the runtime address is 10.10.1.2/20. Three different intents in one stanza for the secure-enclave bridge.
srv02gate and srv05access both report “runtime and permanent firewalld configuration differ (public/interfaces)”. On srv05access the permanent public zone has no interfaces while eth0 is assigned at runtime; on srv02gate the permanent zone lists the six. Either way the firewall’s interface bindings are not fully reproducible from disk.
srv03mm /etc/network/interfaces configures IPv6 autoconf on enp1s0, which does not exist (the NIC is enp2s0).
srv02gate hostname is srv02gagte and its FQDN is unqualified — this propagates into logs, certificates and any host-based authorisation.
srv05access wlan0 and both hypervisors’ fwbr* bridges are present at runtime but absent from disk (expected for fwbr*, which PVE creates on VM start; not expected for wlan0).

S-12 — Extra network daemons on the hypervisors — Low

Both hypervisors run nginx on 80 and 443, reachable from VLAN 200 via GROUP-management-IN, in addition to pveproxy (8006) and spiceproxy (3128). srv06hv additionally runs Technitium DNS (53, plus the 5380 admin console bound to all interfaces) and DHCP (67/udp on four bridge addresses).

The hypervisors are the highest-value hosts in the estate: a root compromise yields every VM. Running a web server and a DNS/DHCP service in the same namespace adds two remote-code-execution surfaces to that host for no virtualisation benefit. 5380 is currently blocked by the PVE ruleset, which is the only thing standing between VLAN 200 and a second DNS admin console.

S-13 — Tunnelling software on both cross-VLAN hosts — Low

srv05access: xray-jumper.service listening on 127.0.0.1:10086 (tcp+udp).
srv02gate: xray.service on 127.0.0.1:18443, fronted by an nginx listener on 127.0.0.1:8443.

Both are loopback-bound, so neither is an inbound exposure, and both are presumably intentional. They are recorded because they sit on the two hosts that touch every VLAN, and because a proxy that terminates on localhost behind a public-facing nginx vhost is a policy-bypass channel: it can carry arbitrary traffic in and out of the estate without traversing any of the zone rules analysed above. Their configuration files were not collected.

S-14 — Patch cadence and OS drift — Low

Host	Uptime	Kernel	Note
srv02gate	247d	6.12.47+rpt-rpi-v8	~8 months without a kernel update, on the most exposed host
srv01hv	119d	6.14.8-2-pve	Debian 13.0 while srv06hv is 13.3
srv04fs	102d	6.12.86+deb13	primary file server
srv06hv	38d	6.17.9-1-pve	current
srv05access	23d	6.12.47+rpt-rpi-2712	Debian 13.6
srv03mm	2h	6.1.0-52	Debian 12 (bookworm) — one major release behind the rest

S-15 — Collector drops the default zone, producing false `filtered` verdicts — Low (tooling)

This is a defect in scripts/collect_host_env.py that affects the correctness of the deliverable, not a property of the network.

firewall-cmd --get-active-zones emits the default zone with an annotation:

public (default)
interfaces: eth0.50 eth0.300 eth0.200 eth0.10 eth0.1 eth0

and --list-all-zones heads it public (default, active). The parser does not strip the parenthesised annotation, so:

section 4.1 “Active Zones” omits public entirely on both firewalld hosts;
section 4.2 therefore omits its effective ports;
section 5 renders public (default): zone not found and falls through to a filtered verdict;
the header summary undercounts: srv02gate reports “firewalld zones (active) 1” against an actual 2, srv05access “3” against an actual 4.

Impact on srv02gate: the report claims 3 reachable ports and 36 filtered. The nft ruleset shows 27 accept rules applying to six interfaces; at least 22 listening ports are reachable. The report understates that host’s attack surface by an order of magnitude. Impact on srv05access is smaller (the untagged eth0 path is missed) because its three custom zones were parsed correctly.

Suggested fix in the zone-name parser: split on whitespace and discard any trailing (...) token, in both the --get-active-zones and --list-all-zones handlers, and treat the default zone as the fallback for any interface not otherwise assigned. Regression fixture: the fw.active_zones and fw.zones_runtime appendix blocks from hostenv_srv02gate_20260826T123456Z.md.

4. Firewall configuration issues, by host

Host	Issue	Findings
srv03mm	No packet filter. Every service on VLAN 200.	S-01
srv04fs	No packet filter. Every service on VLAN 200 and VLAN 400.	S-01, S-10
srv02gate	Six VLANs of differing trust share one permissive zone; 27 allowances of which 4 serve nothing; DMZ correctly restricted, guest/IoT/enclave not; runtime ≠ permanent.	S-02, S-11
srv05access	Sound per-VLAN zoning. SSH offered to DMZ and IoT; unauthenticated 9090 to all of VLAN 200; `22/udp` allowed for no reason; untagged `eth0` in the permissive default zone; runtime ≠ permanent.	S-04, S-05, S-11
srv01hv	Correct default-deny. Stale `vmbr2nas` rule; SMB/NFS grants on the storage VLAN for services not run; enclave and native VLAN governed only by an unverified ipset; nginx grant on VLAN 200.	S-07, S-09, S-12
srv06hv	Correct default-deny. Stale `vmbr4nas` and `vmbr2iot` rules; no IoT rule at all; same SMB/NFS over-grant; unverified ipset; `docker`/`hvintrav1` path outside the `fwln+` filter; DNS/DHCP/nginx on a hypervisor.	S-07, S-08, S-09, S-12
all	ICMP redirects accepted and sent, no martian logging, rp_filter off or loose.	S-06

Two structural observations across the set:

Three different firewall technologies are in use (firewalld/nftables, PVE/iptables-legacy, and nothing), each with its own default and its own failure mode. There is no single place to answer “who can reach port X”.
Two hosts do all the cross-VLAN work (srv02gate with six VLANs, srv05access with four) and both have rp_filter=0 and two default routes. That combination makes source-based rules unenforceable on exactly the hosts that most need them.

5. Recommended actions

Priority is by risk-reduction per unit of effort. Nothing below has been applied; this engagement is read-only.

P1 — do first

Fence srv04fs and srv03mm (S-01). Install and enable firewalld on both, with a default-deny posture, and split VLAN 200 from VLAN 400 on srv04fs. Concrete configuration in section 6.1. Before that, pin the NFS ephemeral ports (section 6.1) so the rules can be written at all.
Confirm the TFTP configuration on srv04fs (S-10): read /etc/default/tftpd-hpa for the root directory and the -c/--create flag. If write access is enabled, disable it or stop the service pending review.
Split srv02gate’s public zone (S-02). Guest (50), IoT (10) and enclave (300) must not share a zone with VLAN 200. Concrete configuration in section 6.2. Highest-value single change: move 5380/tcp (DNS admin) and 1812/1813 (RADIUS) off the guest and IoT interfaces.
Retrieve and review the PVEFW-0-management ipset on both hypervisors (S-09): ipset list PVEFW-0-management-v4. Constrain it to VLAN 2871 and/or named admin hosts. Add ipset save to the collector so it is captured in future runs.
Verify /etc/exports, smb.conf and sshd_config on srv03mm, srv04fs and srv05access (S-01, S-04, S-10). These four files determine whether the exposures above are exploitable, and none was collected.

P2 — next

Remove SSH from the DMZ and IoT zones on srv05access (S-04), or restrict it by source to a named jump host. Move eth0 (untagged) out of public into drop. Section 6.3.
Put an authenticating proxy in front of Prometheus, or restrict 9090 by source (S-05). Bind node_exporter to a single management address on all six hosts (--web.listen-address=10.x.x.x:9100) rather than *.
Apply the sysctl hardening in section 6.5 (S-06), starting with accept_redirects=0 and log_martians=1, which are safe everywhere. Defer rp_filter=1 on srv02gate and srv05access until their duplicate default routes are resolved.
Prune the Proxmox security groups (S-07): drop the SMB and 2049 entries from GROUP-nas-IN, remove the stale interface rules, and add an explicit IoT rule to srv06hv’s node config. Section 6.4.
Enable the per-VM firewall on tap106i2, tap104i2 and tap110i1 (S-08) — set firewall=1 on those NICs in the guest configs so Proxmox inserts the fwbr bridge. tap110i1 on production VLAN 200 first.
Patch and reboot srv02gate, srv01hv and srv04fs (S-14); schedule srv03mm’s Debian 12 → 13 upgrade.

P3 — hygiene and hardening

Rework the srv06hv docker path (S-08): either rename the veth pair to match fwln+ so PVE filters it, or detach the docker bridge from hvintrav1 and stop nesting VLAN 1 inside VLAN 214.
Fix the on-disk configuration defects in S-11 — the srv06hv esn2f0.* typos are the urgent one, because the storage and DMZ bridges will not come up correctly from a cold boot.
Run firewall-cmd --runtime-to-permanent (after review) on srv02gate and srv05access so the audited state survives a reload.
Move nginx off both hypervisors, or bind it to 127.0.0.1 and drop the 80/443 grants from GROUP-management-IN (S-12). Consider moving srv06hv’s DNS/DHCP role into a VM.
Bind loopback-only services explicitly rather than relying on the firewall: rpcbind, avahi-daemon and upsd on srv05access are all 0.0.0.0 and blocked only by firewalld. If firewalld ever fails to start, they are exposed. rpcbind can be disabled entirely on hosts that are not NFS clients or servers.
Document the Xray tunnels (S-13) or remove them.
Fix the collector’s zone parser (S-15) and re-collect srv03mm and srv04fs with version 1.1.0 (G-01).

6. Recommended firewall configuration

Reference configurations, not applied. Each assumes the VLAN roles in Designated VLANs.md. Substitute your own management CIDR for <MGMT> = 10.0.1.0/24 (VLAN 2871) and monitoring host <MON> = 10.1.1.14 (srv05access, the Prometheus server).

6.1 srv04fs and srv03mm — from nothing to default-deny

First make NFS’s ports predictable, otherwise no static rule can cover mountd/statd:

# /etc/nfs.conf
[mountd]
port = 20048
[statd]
port = 32765
outgoing-port = 32766
[lockd]
port = 32803
udp-port = 32803

Then, on srv04fs — the point is that VLAN 200 and VLAN 400 get different policies, which is impossible today:

# storage VLAN 400: file services live here
firewall-cmd --permanent --new-zone=storage
firewall-cmd --permanent --zone=storage --add-service=ssh
firewall-cmd --permanent --zone=storage --add-service=nfs
firewall-cmd --permanent --zone=storage --add-port=20048/tcp --add-port=20048/udp
firewall-cmd --permanent --zone=storage --add-port=32765/tcp --add-port=32765/udp
firewall-cmd --permanent --zone=storage --add-port=32803/tcp --add-port=32803/udp
firewall-cmd --permanent --zone=storage --add-service=samba
firewall-cmd --permanent --zone=storage --add-rich-rule=\
'rule family=ipv4 source address=<MON> port port=9100 protocol=tcp accept'
firewall-cmd --permanent --zone=storage --change-interface=ens4f0.400

# main VLAN 200: administration and SMB clients only, no NFS, no TFTP, no FTP
firewall-cmd --permanent --new-zone=srv-main
firewall-cmd --permanent --zone=srv-main --add-service=ssh
firewall-cmd --permanent --zone=srv-main --add-service=samba
firewall-cmd --permanent --zone=srv-main --add-rich-rule=\
'rule family=ipv4 source address=<MON> port port=9100 protocol=tcp accept'
firewall-cmd --permanent --zone=srv-main --change-interface=ens4f0.200

# the untagged trunk parent gets nothing
firewall-cmd --permanent --zone=drop --change-interface=ens4f0
firewall-cmd --permanent --set-default-zone=drop
firewall-cmd --reload

TFTP and vsftpd are deliberately absent. If TFTP is genuinely required (network boot), give it its own zone bound to the one VLAN that needs it and confirm the service is read-only:

firewall-cmd --permanent --zone=storage --add-service=tftp # only if required

On srv03mm the same shape, with one VLAN:

firewall-cmd --permanent --new-zone=srv-main
firewall-cmd --permanent --zone=srv-main --add-service=ssh
firewall-cmd --permanent --zone=srv-main --add-service=samba
firewall-cmd --permanent --zone=srv-main --add-port=8096/tcp # Jellyfin
firewall-cmd --permanent --zone=srv-main --add-rich-rule=\
'rule family=ipv4 source address=10.1.1.13 port port=2049 protocol=tcp accept'
firewall-cmd --permanent --zone=srv-main --add-rich-rule=\
'rule family=ipv4 source address=<MON> port port=9100 protocol=tcp accept'
firewall-cmd --permanent --zone=srv-main --add-rich-rule=\
'rule family=ipv4 source address=<MON> port port=44322 protocol=tcp accept'
firewall-cmd --permanent --zone=srv-main --change-interface=enp2s0.200
firewall-cmd --permanent --zone=drop --change-interface=enp2s0
firewall-cmd --permanent --set-default-zone=drop
firewall-cmd --reload

NFS on srv03mm exists to serve tank/backup-mirror to srv04fs only, hence the single-source rich rule rather than --add-service=nfs. PCP is restricted to the monitoring host. rpcbind should be masked if the NFS server is moved to NFSv4-only.

6.2 srv02gate — split `public` by trust level

The goal: DNS and DHCP everywhere (that is the host’s job), everything else only where it belongs.

# 1. A zone for the least-trusted segments: resolver and addressing only.
firewall-cmd --permanent --new-zone=untrusted
firewall-cmd --permanent --zone=untrusted --set-target=DROP
firewall-cmd --permanent --zone=untrusted --add-service=dns
firewall-cmd --permanent --zone=untrusted --add-service=dhcp
firewall-cmd --permanent --zone=untrusted --change-interface=eth0.50 # guest
firewall-cmd --permanent --zone=untrusted --change-interface=eth0.10 # IoT
firewall-cmd --permanent --zone=untrusted --change-interface=eth0.300 # enclave

# 2. The DMZ keeps its current, correct policy.
# (block/eth0.1024 with dns+dhcp — unchanged)

# 3. VLAN 200: administration and the published web services.
firewall-cmd --permanent --new-zone=infra
firewall-cmd --permanent --zone=infra --add-service=dns
firewall-cmd --permanent --zone=infra --add-service=dhcp
firewall-cmd --permanent --zone=infra --add-service=http
firewall-cmd --permanent --zone=infra --add-service=https
firewall-cmd --permanent --zone=infra --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> service name=ssh accept'
firewall-cmd --permanent --zone=infra --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> port port=5380 protocol=tcp accept'
firewall-cmd --permanent --zone=infra --add-rich-rule=\
'rule family=ipv4 source address=<MON> port port=9100 protocol=tcp accept'
firewall-cmd --permanent --zone=infra --change-interface=eth0.200

# 4. VLAN 1 / native: the network-equipment management plane.
# Restrict RADIUS and the UniFi ports to the switch/AP subnet only.
firewall-cmd --permanent --new-zone=netmgmt
firewall-cmd --permanent --zone=netmgmt --set-target=DROP
firewall-cmd --permanent --zone=netmgmt --add-service=dns
firewall-cmd --permanent --zone=netmgmt --add-service=dhcp
firewall-cmd --permanent --zone=netmgmt --add-rich-rule=\
'rule family=ipv4 source address=10.0.2.0/24 service name=radius accept'
firewall-cmd --permanent --zone=netmgmt --add-rich-rule=\
'rule family=ipv4 source address=10.0.2.0/24 port port=8080 protocol=tcp accept'
firewall-cmd --permanent --zone=netmgmt --add-rich-rule=\
'rule family=ipv4 source address=10.0.2.0/24 port port=3478 protocol=udp accept'
firewall-cmd --permanent --zone=netmgmt --add-rich-rule=\
'rule family=ipv4 source address=10.0.2.0/24 port port=5514 protocol=udp accept'
firewall-cmd --permanent --zone=netmgmt --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> port port=8443 protocol=tcp accept'
firewall-cmd --permanent --zone=netmgmt --change-interface=eth0.1
firewall-cmd --permanent --zone=drop --change-interface=eth0

# 5. Retire the blanket allowances entirely.
firewall-cmd --permanent --zone=public --remove-port=22/udp
firewall-cmd --permanent --zone=public --remove-port=1900/udp
firewall-cmd --permanent --zone=public --remove-port=8843/tcp
firewall-cmd --permanent --zone=public --remove-port=27117/tcp
firewall-cmd --permanent --zone=public --remove-port=5671/tcp
firewall-cmd --permanent --zone=public --remove-port=6789/tcp
firewall-cmd --permanent --zone=public --remove-port=8880-8882/tcp
firewall-cmd --permanent --zone=public --remove-port=11443/tcp
firewall-cmd --permanent --zone=public --remove-port=5380/tcp
firewall-cmd --permanent --zone=public --remove-service=radius
firewall-cmd --permanent --zone=public --remove-service=prometheus-node-exporter
firewall-cmd --permanent --zone=public --remove-service=ssh
firewall-cmd --permanent --set-default-zone=drop
firewall-cmd --reload

Note the substantive decisions embedded above: the UniFi controller’s device-facing ports are opened only towards the subnet where switches and APs live (10.0.2.0/24, VLAN 1); its admin UI (8443) and the DNS admin console (5380) only towards the management network; RADIUS only towards the authenticators, never towards clients. 27117 (MongoDB) is removed outright. 8880-8882 (UniFi guest portal HTTP/HTTPS redirect) is the one case where a guest-facing allowance may be genuinely required — if so, add it back to untrusted explicitly rather than leaving the whole zone open.

Verify afterwards with the same evidence path used in this audit:

nft list chain inet firewalld filter_IN_untrusted_allow
firewall-cmd --get-active-zones

6.3 srv05access — tighten the choke host

# DMZ and IoT get no SSH; if a break-glass path is needed, pin it by source.
firewall-cmd --permanent --zone=dmz --remove-service=ssh
firewall-cmd --permanent --zone=restrict-ssh-only --remove-service=ssh
firewall-cmd --permanent --zone=restrict-ssh-only --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> service name=ssh accept'

# Prometheus by source, not by VLAN.
firewall-cmd --permanent --zone=restrict-regular --remove-service=prometheus
firewall-cmd --permanent --zone=restrict-regular --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> port port=9090 protocol=tcp accept'

# SSH on VLAN 200 by source as well.
firewall-cmd --permanent --zone=restrict-regular --remove-service=ssh
firewall-cmd --permanent --zone=restrict-regular --add-rich-rule=\
'rule family=ipv4 source address=<MGMT> service name=ssh accept'

# The untagged trunk parent should carry no host services.
firewall-cmd --permanent --zone=drop --change-interface=eth0
firewall-cmd --permanent --zone=public --remove-port=22/udp
firewall-cmd --permanent --set-default-zone=drop
firewall-cmd --reload

Then bind the services that are currently protected only by the firewall:

# rpcbind: disable if not required, else
systemctl mask rpcbind.socket rpcbind.service
# avahi-daemon
/etc/avahi/avahi-daemon.conf: allow-interfaces=eth0.200
# NUT upsd
/etc/nut/upsd.conf: LISTEN 127.0.0.1 3493
# node_exporter
ExecStart=... --web.listen-address=10.1.1.14:9100
# Prometheus
ExecStart=... --web.listen-address=127.0.0.1:9090 # front with authenticating proxy

6.4 srv01hv and srv06hv — Proxmox security groups

Datacenter → Firewall → Security Group. Replace GROUP-nas-IN with a version matching what the hypervisors actually do on VLAN 400 (they are NFS/CIFS clients):

# GROUP-nas-IN — hypervisor is a client, not a server
IN ACCEPT -source 10.255.255.0/24 -p tcp -dport 22 # admin
IN ACCEPT -p udp -dport 67:68 # DHCP
# remove: 111, 2049, 135, 137-139, 445

GROUP-management-IN — drop the web server grants once nginx is bound to loopback (S-12):

IN ACCEPT -p udp -dport 67:68
IN ACCEPT -p tcp -dport 53
IN ACCEPT -p udp -dport 53
IN ACCEPT -source <MGMT> -p tcp -dport 22
# remove: 80/tcp, 443/tcp, unrestricted 22/tcp

Per-node Firewall → set the interface→group bindings to the bridges that exist on that node, and add the missing IoT binding on srv06hv:

Node	Binding
srv01hv	`vmbr4nas`→nas, `vmbr2iot`→dmz-external, `vmbr10ext`→dmz-external, `vmbr1plc`→management, `vmbr0vm`+`hvintra`→pve-basic, `vmbr3sec`→new `GROUP-enclave-IN` (currently default-deny by accident)
srv06hv	`vmbr2nas`→nas, `vmbr10ext`→dmz-external, `vmbr1plc`→management, `vmbr0vm`+`hvintra`→pve-basic, `docker`/`hvintrav1`→explicit DROP

Datacenter → Firewall → Alias/IPSet management: restrict to the VLAN 2871 range and/or named admin hosts, and confirm with ipset list PVEFW-0-management-v4 that it does not contain a production CIDR.

Per-VM: set firewall=1 on net entries 106:net2 (srv01hv), 104:net2 and 110:net1 (srv06hv) so their taps move behind fwbr* bridges.

6.5 Estate-wide sysctl baseline

/etc/sysctl.d/60-net-harden.conf on all six hosts:

# Reject route injection
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
# Do not emit redirects (none of these hosts routes: ip_forward=0)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Source-address validation
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Visibility
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
# Already correct everywhere — pin it
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

Caveat on rp_filter. Strict mode (1) will drop legitimate traffic on srv02gate and srv05access while each carries two default routes, and may affect the hypervisors’ multi-bridge paths. Sequence: apply accept_redirects, send_redirects and log_martians first (safe on all six); then resolve the duplicate default routes on srv02gate and srv05access; then move those two and the hypervisors from rp_filter=2 to 1, verifying with log_martians output before and after. Do not set net.ipv4.ip_forward=1 on any of these hosts — the current 0 is a meaningful control given how many VLANs they each terminate.

7. Evidence gaps

ID	Gap	Effect	Close by
G-01	srv03mm and srv04fs were collected with `collect_host_env.py` 1.0.0, which captured no `nft`/`iptables` output; their firewall state is inferred, not observed	`S-01` rests on an assumption. If a hand-written ruleset exists, the severity drops sharply	Re-run with 1.1.0: `./collect_host_env.py srv03mm srv04fs`
G-02	`PVEFW-0-management-v4/-v6` ipset contents never collected	The most privileged access control on both hypervisors is unverified (`S-09`)	`ipset list PVEFW-0-management-v4`; add `ipset save` to the collector
G-03	srv05access’s `fw.nft` appendix is truncated (“857 more lines”)	Its custom zone chains could not be verified against the zone tables; verdicts for that host rest on `firewall-cmd` output alone	Re-collect, or raise the appendix truncation limit
G-04	Service configuration files not collected: `/etc/exports`, `smb.conf`, `sshd_config`, `/etc/default/tftpd-hpa`, `vsftpd.conf`, `prometheus.yml`, Xray configs	Determines whether `S-01`, `S-04`, `S-05`, `S-10` and `S-13` are exploitable or merely present	Add a read-only `cfg.*` collector group
G-05	No process-level TLS/credential inspection; no view of the nginx vhost configuration on srv02gate, srv01hv, srv06hv	The published web surface (four `443` vhosts on srv02gate) is unmapped	Out of scope for host-env collection; needs a separate config review
G-06	srv02gate’s podman containers were enumerated by published port only (`pasta`, `podman-250104.scope`)	Container images, versions and internal exposure unknown	`podman ps --format json`, `podman image ls`

S-15 is a defect rather than a gap, but it has the same effect on the deliverable: any conclusion previously drawn from section 5 of the two firewalld reports should be re-derived from fw.nft.

8. Method note

Derivation for each verdict in section 2:

firewalld hosts — fw.active_zones for interface→zone binding, then the matching filter_IN_<zone>_allow chain in fw.nft for the accepted port set, cross-checked against fw.zones_runtime and fw.zones_permanent. The filter_INPUT chain was confirmed to end in reject with icmpx admin-prohibited on both hosts, so unmatched traffic is denied.
Proxmox hosts — fw.iptables PVEFW-HOST-IN, walked top to bottom: interface rules jump to a GROUP-*-IN chain, which sets the accept mark via PVEFW-SET-ACCEPT-MARK; a following -m mark --mark 0x80000000 -j RETURN releases marked packets. Interfaces with no rule fall through to the PVEFW-0-management ipset rules and then PVEFW-Drop/DROP.
srv03mm, srv04fs — no ruleset exists in the collection; stated as an assumption (G-01).
Listening sockets — section 3 of each report, which derives from svc.ss (ss -tulpnH) plus svc.pidinfo/svc.dpkg for process attribution.
VLAN and interface facts — sections 2.1–2.6, corroborated against audit-report/NETWORK_TOPOLOGY.md.

No host was contacted and no packet was sent in the production of this document.

Network Topology Report

Mon, 31 Aug 2026 13:00:00 +0000

Network Topology — `srv*` Hosts

Reconstructed switch/port/VLAN topology for the six srv* machines.

Field	Value
Scope	`srv01hv`, `srv02gate`, `srv03mm`, `srv04fs`, `srv05access`, `srv06hv`
Sources	`host-env-scan/hostenv_srv*.md` — sections 2.1–2.6 and the raw `net.lldp` (`lldpctl -f json`) appendix entries; `Designated VLANs.md` for VLAN roles and designated ranges
Method	On-host inspection only (read-only). No switch was logged into, no scanning was performed for this document.
Collection window (UTC)	2026-08-25 23:05 → 2026-08-26 12:35
Revision	2 — re-collected srv01hv and srv02gate folded in; VLAN roles reconciled against `Designated VLANs.md`

Source report files:

Host	Report	Collected (UTC)	Privilege
srv01hv	`hostenv_srv01hv_20260826T123515Z.md`	2026-08-26 12:35	connected as root
srv02gate	`hostenv_srv02gate_20260826T123456Z.md`	2026-08-26 12:34	passwordless sudo
srv03mm	`hostenv_srv03mm_20260825T230531Z.md`	2026-08-25 23:05	sudo via password
srv04fs	`hostenv_srv04fs_20260825T230503Z.md`	2026-08-25 23:05	sudo via password
srv05access	`hostenv_srv05access_20260825T231718Z.md`	2026-08-25 23:17	sudo via password
srv06hv	`hostenv_srv06hv_20260826T121246Z.md`	2026-08-26 12:12	sudo via password

What the re-collection changed. srv02gate’s LLDP table is now populated, which resolves the largest gap in revision 1 (finding T-02) and places the last unattached host on a known switch port. srv01hv was re-run as root and its net.lldp appendix is no longer truncated (finding T-08), but its 10G eth0p0 link still reports no LLDP neighbour — so T-01 stays open, and the absence is now attributable to the peer rather than to insufficient privilege. Interface, VLAN and address data for both hosts are otherwise byte-identical to revision 1; no address or VLAN changed.

1. Switches

Identified purely from LLDP chassis TLVs received by the hosts.

Switch	Model / descr	Chassis MAC	Management IP	Capabilities	Observed from
`TL-SE5226`	TP-Link, `24*2.5GE+2SFP+ L3 Managed Switch`	`24:5a:5f:9b:fd:01`	`10.1.1.3` (mgmt-iface VLAN `200`)	Bridge + Router	srv01hv, srv02gate, srv03mm, srv05access
`USW-Aggregation`	Ubiquiti, `UBNT-USL8A`	`0c:ea:14:bf:29:3f`	`10.0.2.6`, `fe80::eea:14ff:febf:293f`	Bridge only	srv04fs, srv06hv

Four TL-SE5226 access ports are now accounted for (TG1/0/4, TG1/0/6, TG1/0/18, TG1/0/20) and two USW-Aggregation SFP+ ports (Port 4, Port 6).

10.1.1.3 is simultaneously the TL-SE5226’s management address and the VLAN 200 default gateway of srv01hv, srv03mm, srv04fs, srv05access and srv06hv — the TL-SE5226 is therefore the L3 edge for VLAN 200.

An inter-switch trunk must exist, on three independent grounds:

srv04fs and srv06hv attach to the L2-only USW-Aggregation yet route VLAN 200 through 10.1.1.3 on the TL-SE5226.
VLAN 1024 (DMZ) is live on hosts attached to both switches.
The USW-Aggregation’s own management address 10.0.2.6 sits in VLAN 1 10.0.2.0/24, the same subnet as srv02gate’s eth0.1 10.0.2.3 — and srv02gate is now confirmed to hang off the TL-SE5226 (TG1/0/18).

The trunk link itself was still not directly observed; no host sits on it.

2. Host → switch → port → VLAN

Uplinks with a live carrier, and the VLANs each one trunks.

Host	Hardware / OS	Uplink NIC (driver, Mb/s)	MAC	Switch	Port	Port description	VLANs advertised by port	VLANs configured on host
srv01hv	Minisforum MS-A2, Debian 13 / PVE 6.14.8	`enp3s0` (r8169, 2500)	`38:05:25:33:67:cf`	TL-SE5226	`TG1/0/4`	TG1/0/4 Interface	10 (System-VLAN), 1 (pvid)	10, 200, 300
srv01hv	"	`eth0p0` (i40e, 10000)	`38:05:25:33:67:d2`	no LLDP neighbour	—	—	—	204, 214, 400, 1024
srv02gate	Raspberry Pi (`rpi-v8`), Debian 13	`eth0` (bcmgenet, 1000)	`d8:3a:dd:99:8b:43`	TL-SE5226	`TG1/0/18`	TG1/0/18 Interface	1 (pvid, System-VLAN)	1, 10, 50, 200, 300, 1024
srv03mm	UGREEN DXP2800, Debian 12	`enp2s0` (igc, 2500)	`6c:1f:f7:56:8e:da`	TL-SE5226	`TG1/0/6`	TG1/0/6 Interface	200 (System-VLAN), 1 (pvid)	200
srv04fs	Dell PowerEdge T360, Debian 13	`ens4f0` (bnx2x, 10000)	`98:b7:85:21:4a:69`	USW-Aggregation	`Port 4`	`SFP_ 4`	1 (pvid)	200, 400
srv05access	Raspberry Pi 5 (`rpi-2712`), Debian 13	`eth0` (macb, 1000)	`d8:3a:dd:c5:13:da`	TL-SE5226	`TG1/0/20`	TG1/0/20 Interface	10 (System-VLAN), 1 (pvid)	10, 200, 1024, 2871
srv06hv	Dell PowerEdge R740xd, Debian 13 / PVE 6.17.9	`ens2f0` (qede, 10000)	`f4:c7:aa:57:15:98`	USW-Aggregation	`Port 6`	`SFP_ 6`	1 (pvid)	200, 204, 214, 214.1, 400, 1024

srv05access negotiated 1000BaseTFD on TG1/0/20; all TL-SE5226 ports report mfs 9216. eth0p0 on srv01hv is the only live uplink in the estate whose switch and port remain unidentified (T-01).

Interfaces with no switch attachment (carrier down)

Host	Interfaces
srv01hv	`enp4s0` (igc), `enp5s0f0np0` (i40e), `wlp6s0`
srv02gate	`wlan0` (brcmfmac)
srv04fs	`eno8303`, `eno8403` (tg3), `ens4f1` (bnx2x)
srv05access	`wlan0` (brcmfmac)
srv06hv	`ens2f1`, `ens2f2`, `ens2f3` (qede), `nic0`–`nic3` (igb)

3. Per-host VLAN → interface → address mapping

srv01hv (Proxmox, dual-homed 2.5G + 10G)

VLAN	VLAN iface	Parent	Bridge	Address
10	`enp3s0.10`	`enp3s0` (TL-SE5226 TG1/0/4)	`vmbr2iot`	`172.17.1.6/16`
200	`enp3s0.200`	`enp3s0`	`vmbr1plc`	`10.1.1.11/20`
300	`enp3s0.300`	`enp3s0`	`vmbr3sec`	`10.10.1.2/20`
204	`eth0p0.204`	`eth0p0` (switch unknown)	`vmbr0vm`	`10.128.128.20/24`
214	`eth0p0.214`	`eth0p0`	`hvintra`	`10.129.0.2/24`
400	`eth0p0.400`	`eth0p0`	`vmbr4nas`	`10.255.255.7/24`
1024	`eth0p0.1024`	`eth0p0`	`vmbr10ext`	`172.16.1.6/16`

Default route: 10.1.1.3 via vmbr1plc. Guest fan-out via Proxmox fwbr<vmid>i<n> / fwln / fwpr veth pairs and tap<vmid>i<n> into vmbr0vm, vmbr1plc, vmbr2iot, vmbr4nas (VMs 105, 106, 107).

srv06hv (Proxmox, single 10G uplink)

VLAN	VLAN iface	Bridge	Address
200	`ens2f0.200`	`vmbr1plc`	`10.1.1.15/20`
204	`ens2f0.204`	`vmbr0vm`	`10.128.128.2/24`
214	`ens2f0.214`	`hvintra`	`10.129.0.1/24`
1 (over 214)	`ens2f0.214.1`	`hvintrav1` → `docker`	none
400	`ens2f0.400`	`vmbr2nas`	`10.255.255.1/24`
1024	`ens2f0.1024`	`vmbr10ext`	`172.16.1.3/16`

Default route: 10.1.1.3 via vmbr1plc. Guest fan-out for VMs 100, 101, 102, 103, 104, 110, 112 plus a ln_docker/pr_docker veth pair into hvintrav1. ens2f0.214.1 is a double-tagged (802.1Q-in-Q) stack: VLAN 1 nested inside VLAN 214. srv06hv carries no VLAN 10 (IoT) interface.

srv02gate (router-ish Pi, 6 VLANs on one 1G link)

Uplink: eth0 → TL-SE5226 TG1/0/18.

VLAN	VLAN iface	Address	Notes
1	`eth0.1`	`10.0.2.3/24`	DHCP, gw `10.0.2.1`; same subnet as USW mgmt `10.0.2.6`; not in `Designated VLANs.md` (T-10)
10	`eth0.10`	`172.17.1.2/16`	IoT
50	`eth0.50`	`192.168.1.2/24`	Guest; designated, not in audit scope
200	`eth0.200`	`10.1.1.10/20`	also the DNS server used by srv03mm
300	`eth0.300`	`10.10.1.1/20`	Secure Enclave; designated, not in audit scope
1024	`eth0.1024`	`172.16.1.2/16`	DMZ

This is the widest VLAN reach of any srv* host — six VLANs spanning Guest, IoT, DMZ, Secure Enclave and main internal — on a single 1G access port.

Two default routes: 10.1.1.1 via eth0.200 (static) and 10.0.2.1 via eth0.1 (DHCP). Physical eth0 also holds a link-local 169.254.252.56/16.

srv03mm

VLAN	VLAN iface	Address
200	`enp2s0.200`	`10.1.1.12/20`

Default route 10.1.1.3; nameserver 10.1.1.10 (srv02gate).

srv04fs

VLAN	VLAN iface	Address
200	`ens4f0.200`	`10.1.1.13/20`
400	`ens4f0.400`	`10.255.255.9/24`

Both addresses via DHCP; default route 10.1.1.3 via ens4f0.200.

srv05access (choke / multihomed audit host)

VLAN	VLAN iface	Address
10	`eth0.10`	`172.17.1.3/16`
200	`eth0.200`	`10.1.1.14/20`
1024	`eth0.1024`	`172.16.1.5/16`
2871	`eth0.2871`	`10.0.1.15/24`

Two default routes: 10.1.1.3 via eth0.200 and 10.0.1.1 via eth0.2871. Physical eth0 also holds 169.254.226.139/16. This is the only srv* host present in VLAN 2871, and the only one reaching all four audited VLANs.

4. VLAN inventory

Roles and designated ranges are taken from Designated VLANs.md. “Audit scope” is the four VLANs authorized in TASK.md / AGENTS.md — the designation file is a network-design document, not an extension of scan authorization.

VLAN	Designated role	Designated range	Observed subnet	Status	`srv*` addresses
1	not designated	—	`10.0.2.0/24`	undesignated, in production	srv02gate `10.0.2.3`; USW-Aggregation mgmt `10.0.2.6`; gw `10.0.2.1`
10	IoT	`172.17.1.0/16`	`172.17.0.0/16`	in audit scope	srv02gate `.1.2`, srv05access `.1.3`, srv01hv `.1.6`
50	Guest	`192.168.1.1/24`	`192.168.1.0/24`	designated, not in scope	srv02gate `192.168.1.2`
200	Main internal	`10.1.1.0/20`	`10.1.0.0/20`	in audit scope	gate `.10`, srv01hv `.11`, srv03mm `.12`, srv04fs `.13`, srv05access `.14`, srv06hv `.15`; gw `10.1.1.3`
204	VMs Interconnect	`10.128.128.0/24`	`10.128.128.0/24`	designated, not in scope	srv01hv `.20`, srv06hv `.2`
214	HVs Interconnect	`10.129.0.0/24`	`10.129.0.0/24`	designated, not in scope	srv01hv `10.129.0.2`, srv06hv `10.129.0.1`
214.1	not designated	—	none	undesignated, double tag inside 214	srv06hv `hvintrav1` (no IP), feeds `docker`
300	Secure Enclave	`10.10.1.0/20`	`10.10.0.0/20`	designated, not in scope	srv02gate `10.10.1.1`, srv01hv `10.10.1.2`
400	Network Storage	`10.255.255.0/24`	`10.255.255.0/24`	designated, not in scope	srv06hv `.1`, srv01hv `.7`, srv04fs `.9`
1024	DMZ	`172.16.1.0/24`	`172.16.0.0/16`	in audit scope	gate `.1.2`, srv06hv `.1.3`, srv05access `.1.5`, srv01hv `.1.6`
2871	Management (isolated)	`10.0.1.1/24`	`10.0.1.0/24`	in audit scope	srv05access `10.0.1.15` only; gw `10.0.1.1`

Every observed host address falls inside its designated range. No host is addressed outside the design, and no designated VLAN carries an address from the wrong block.

All nine distinct designated VLANs (10, 50, 200, 204, 214, 300, 400, 1024, 2871) are present on at least one srv* host; none is unused. Conversely two live VLANs — 1 and the 214.1 double tag — are absent from the designation file (T-10).

Notation: the designated ranges use host-style bases (10.1.1.0/20, 172.17.1.0/16, 192.168.1.1/24, 10.0.1.1/24) rather than normalized network addresses, matching the existing TASK.md convention. Per AGENTS.md this is deliberate and is not to be “corrected”; the “Observed subnet” column above carries the normalized form for comparison. The DMZ discrepancy is the same one already documented in AGENTS.md: designated 172.16.1.0/24, but every host interface is configured /16. All observed DMZ addresses nonetheless fall within 172.16.1.0/24, so the intent holds even though the masks are wider.

VLANs 1, 50, 204, 214, 214.1, 300 and 400 fall outside the four authorized scan ranges. They appear here only because they were read from on-host configuration; nothing was scanned in them.

5. Topology diagrams

5.1 Physical link layer — switch, port, trunked VLANs

flowchart TB SW1["TL-SE5226
TP-Link L3 managed switch
24x2.5GE + 2 SFP+
chassis 24:5a:5f:9b:fd:01
mgmt 10.1.1.3 on VLAN 200
caps Bridge + Router"] SW2["USW-Aggregation
Ubiquiti UBNT-USL8A
chassis 0c:ea:14:bf:29:3f
mgmt 10.0.2.6 on VLAN 1
caps Bridge only"] SWX["switch UNKNOWN
no LLDP neighbour on link
finding T-01"] H1A["srv01hv : enp3s0
r8169, 2500 Mb/s
38:05:25:33:67:cf"] H1B["srv01hv : eth0p0
i40e, 10000 Mb/s
38:05:25:33:67:d2"] MM["srv03mm : enp2s0
igc, 2500 Mb/s
6c:1f:f7:56:8e:da"] AC["srv05access : eth0
macb, 1000 Mb/s
d8:3a:dd:c5:13:da
CHOKE HOST"] FS["srv04fs : ens4f0
bnx2x, 10000 Mb/s
98:b7:85:21:4a:69"] H6["srv06hv : ens2f0
qede, 10000 Mb/s
f4:c7:aa:57:15:98"] GW["srv02gate : eth0
bcmgenet, 1000 Mb/s
d8:3a:dd:99:8b:43"] SW1 -.-|"inter-switch trunk
required by routing, never observed"| SW2 SW1 ---|"TG1/0/4
tagged 10, 200, 300"| H1A SW1 ---|"TG1/0/6
tagged 200"| MM SW1 ---|"TG1/0/18
tagged 1, 10, 50, 200, 300, 1024"| GW SW1 ---|"TG1/0/20
tagged 10, 200, 1024, 2871"| AC SW2 ---|"Port 4 / SFP_ 4
tagged 200, 400"| FS SW2 ---|"Port 6 / SFP_ 6
tagged 200, 204, 214, 400, 1024"| H6 SWX ---|"port unknown
tagged 204, 214, 400, 1024"| H1B SWX -.-|"likely the same chassis as SW2
8x SFP+ aggregation, 10G peers
inference only"| SW2 classDef sw fill:#0f2f46,stroke:#061722,color:#ffffff classDef unk fill:#4a1f1f,stroke:#220c0c,color:#ffffff,stroke-dasharray:5 4 classDef nic fill:#14331d,stroke:#07180d,color:#ffffff classDef choke fill:#5a4310,stroke:#2b2007,color:#ffffff class SW1,SW2 sw class SWX unk class H1A,H1B,MM,FS,H6,GW nic class AC choke

Advertised-VLAN caveat: the “tagged” lists above come from each host’s own 802.1Q sub-interfaces, not from the switches’ LLDP VLAN TLVs. Neither switch advertises its full trunk allow-list — see finding T-03.

5.2 VLAN membership

flowchart LR subgraph HOSTS["srv hosts"] direction TB GW["srv02gate"] H1["srv01hv"] MM["srv03mm"] FS["srv04fs"] AC["srv05access"] H6["srv06hv"] end subgraph INSCOPE["Designated, in audit scope"] direction TB V10["VLAN 10 — IoT
172.17.0.0/16"] V200["VLAN 200 — Main internal
10.1.0.0/20
gw 10.1.1.3"] V1024["VLAN 1024 — DMZ
172.16.0.0/16"] V2871["VLAN 2871 — Management, isolated
10.0.1.0/24
gw 10.0.1.1"] end subgraph OUTSCOPE["Designated, outside audit scope"] direction TB V50["VLAN 50 — Guest
192.168.1.0/24"] V204["VLAN 204 — VMs Interconnect
10.128.128.0/24"] V214["VLAN 214 — HVs Interconnect
10.129.0.0/24"] V300["VLAN 300 — Secure Enclave
10.10.0.0/20"] V400["VLAN 400 — Network Storage
10.255.255.0/24"] end subgraph UNDESIG["Live but NOT in Designated VLANs.md — T-10"] direction TB V1["VLAN 1 — native, switch mgmt
10.0.2.0/24
gw 10.0.2.1"] V2141["VLAN 1 nested in 214
double tagged, no IP"] end GW ---|"10.0.2.3 dhcp"| V1 GW ---|"172.17.1.2"| V10 GW ---|"192.168.1.2"| V50 GW ---|"10.1.1.10"| V200 GW ---|"10.10.1.1"| V300 GW ---|"172.16.1.2"| V1024 H1 ---|"172.17.1.6"| V10 H1 ---|"10.1.1.11"| V200 H1 ---|"10.128.128.20"| V204 H1 ---|"10.129.0.2"| V214 H1 ---|"10.10.1.2"| V300 H1 ---|"10.255.255.7"| V400 H1 ---|"172.16.1.6"| V1024 MM ---|"10.1.1.12"| V200 FS ---|"10.1.1.13"| V200 FS ---|"10.255.255.9"| V400 AC ---|"172.17.1.3"| V10 AC ---|"10.1.1.14"| V200 AC ---|"172.16.1.5"| V1024 AC ---|"10.0.1.15"| V2871 H6 ---|"10.1.1.15"| V200 H6 ---|"10.128.128.2"| V204 H6 ---|"10.129.0.1"| V214 H6 ---|"no address"| V2141 H6 ---|"10.255.255.1"| V400 H6 ---|"172.16.1.3"| V1024 classDef host fill:#14331d,stroke:#07180d,color:#ffffff classDef vin fill:#0f2f46,stroke:#061722,color:#ffffff classDef vout fill:#3a3a3a,stroke:#1a1a1a,color:#ffffff,stroke-dasharray:4 3 classDef vund fill:#4a1f1f,stroke:#220c0c,color:#ffffff,stroke-dasharray:5 4 class GW,H1,MM,FS,AC,H6 host class V10,V200,V1024,V2871 vin class V50,V204,V214,V300,V400 vout class V1,V2141 vund

srv05access is the only srv* host in VLAN 2871, and the only one touching all four audited VLANs. srv06hv has no VLAN 10 interface. VLAN 200 is the only VLAN common to all six hosts. srv02gate is the only host in VLAN 1 and VLAN 50, and carries six of the eleven VLANs by itself.

5.3 Hypervisor bridge fan-out

Guest attachment on the two Proxmox nodes. Solid edges pass through a per-VM firewall bridge (fwbr<vmid>i<n>); dashed edges are raw tap devices attached straight to the bridge, which bypass that filter — see finding T-09.

flowchart LR subgraph SRV01["srv01hv"] direction LR N1A["enp3s0
2500 Mb/s
TL-SE5226 TG1/0/4"] N1B["eth0p0
10000 Mb/s
switch unknown"] B12["vmbr2iot
vlan 10
172.17.1.6/16"] B11["vmbr1plc
vlan 200
10.1.1.11/20"] B13["vmbr3sec
vlan 300
10.10.1.2/20"] B10["vmbr0vm
vlan 204
10.128.128.20/24"] B1H["hvintra
vlan 214
10.129.0.2/24"] B14["vmbr4nas
vlan 400
10.255.255.7/24"] B1E["vmbr10ext
vlan 1024
172.16.1.6/16"] VM105["VM105"] VM106["VM106"] VM107["VM107"] N1A --> B12 N1A --> B11 N1A --> B13 N1B --> B10 N1B --> B1H N1B --> B14 N1B --> B1E B10 --> VM105 B10 --> VM106 B10 --> VM107 B11 --> VM105 B11 --> VM106 B11 --> VM107 B12 --> VM107 B14 -.->|"tap106i2 raw"| VM106 end subgraph SRV06["srv06hv"] direction LR N6["ens2f0
10000 Mb/s
USW-Aggregation Port 6"] B61["vmbr1plc
vlan 200
10.1.1.15/20"] B60["vmbr0vm
vlan 204
10.128.128.2/24"] B6H["hvintra
vlan 214
10.129.0.1/24"] B6H1["hvintrav1
vlan 1 in 214
no IP"] B6D["docker bridge"] B62["vmbr2nas
vlan 400
10.255.255.1/24"] B6E["vmbr10ext
vlan 1024
172.16.1.3/16"] G6["VM100 VM101 VM102
VM103 VM104 VM112"] VM110["VM110"] VM102["VM102"] VM104["VM104"] N6 --> B61 N6 --> B60 N6 --> B6H N6 --> B6H1 N6 --> B62 N6 --> B6E B6H1 ---|"pr_docker / ln_docker veth"| B6D B60 --> G6 B60 --> VM110 B61 --> G6 B62 --> VM102 B61 -.->|"tap110i1 raw"| VM110 B62 -.->|"tap104i2 raw"| VM104 end classDef nic fill:#0f2f46,stroke:#061722,color:#ffffff classDef br fill:#14331d,stroke:#07180d,color:#ffffff classDef vm fill:#3a3a3a,stroke:#1a1a1a,color:#ffffff class N1A,N1B,N6 nic class B10,B11,B12,B13,B14,B1E,B1H,B60,B61,B62,B6E,B6H,B6H1,B6D br class VM105,VM106,VM107,G6,VM110,VM102,VM104 vm

vmbr3sec, vmbr10ext and hvintra carry no guest interfaces on either node — they exist purely as host-side L3 attachments.

6. Gaps and anomalies

Status key: OPEN — unresolved; RESOLVED — closed by the revision 2 re-collection, retained for provenance.

ID	Status	Summary
T-01	OPEN	srv01hv `eth0p0` switch/port still unidentified
T-02	RESOLVED	srv02gate LLDP now populated — TL-SE5226 `TG1/0/18`
T-03	OPEN	switch “VLANs offered” unusable as a misconfiguration check
T-04	OPEN	switch management shares production VLANs
T-05	OPEN	divergent VLAN 200 default gateways
T-06	OPEN	TL-SE5226 is the sole L3 boundary across internal/DMZ/mgmt
T-07	OPEN	collector renders unnamed LLDP chassis as literal `id`
T-08	RESOLVED	srv01hv `net.lldp` appendix no longer truncated
T-09	OPEN	three guest taps bypass the per-VM firewall bridge
T-10	OPEN	VLAN 1 live in production but absent from `Designated VLANs.md`
T-11	OPEN	`Designated VLANs.md` lists VLAN 400 twice

T-01 — srv01hv `eth0p0` upstream switch/port unresolved — OPEN

The 10G eth0p0 link received no LLDP neighbour, so its switch and port are unknown. It trunks VLANs 204, 214, 400 and 1024; VLAN 400 (10.255.255.7) and 1024 also live on USW-Aggregation-attached hosts (srv04fs 10.255.255.9, srv06hv 10.255.255.1), and its VLAN 214 peer 10.129.0.1 is srv06hv on Port 6.

Revision 2 strengthens the diagnosis without closing the finding. srv01hv was re-collected while logged in as root, so lldpctl ran fully privileged and its appendix output is complete (25 KB of JSON, no truncation) — yet eth0p0 still does not appear among the LLDP interfaces, while enp3s0 on the same host does. The silence is therefore a property of the peer or of that link, not a collection artifact. This eliminates the “insufficient privilege” explanation that T-02 turned out to be.

Attachment to the USW-Aggregation remains the most probable answer: it is a UBNT-USL8A, an 8-port SFP+ aggregation switch, and both of its known ports face 10G hosts, whereas the TL-SE5226 is a 2.5GE switch with only two SFP+ uplinks. That is still an inference from port-count and subnet adjacency, not observed LLDP, and the port number is unknown. Resolving it needs a switch-side MAC or LLDP table lookup for 38:05:25:33:67:d2, which is outside read-only host inspection.

T-02 — srv02gate returned an empty LLDP table — RESOLVED

Revision 1: lldpd.service was active and lldpctl -f json exited 0, but returned {"lldp": {}}, so the report had no section 2.5 at all. The appendix showed the command had run unprivileged despite the host having passwordless sudo — the r.available vs r.binaries pitfall documented in AGENTS.md.

Revision 2: the re-collection returns a populated neighbour table:

Interface	Switch	Port	Port description	VLANs offered
`eth0`	TL-SE5226 (`24*2.5GE+2SFP+ L3 Managed Switch`)	`TG1/0/18`	TG1/0/18 Interface	1 (pvid, System-VLAN)

srv02gate therefore sits on the TL-SE5226, not the USW-Aggregation — the same switch as srv01hv’s 2.5G leg, srv03mm and srv05access. This closes the last unattached uplink apart from T-01 and supplies the third independent argument for the inter-switch trunk in section 1. Note the chassis TLV carried no mgmt-ip this time, so the switch’s management address is corroborated only by srv03mm’s observation (10.1.1.3, mgmt-iface VLAN 200).

T-03 — “VLANs offered” is not a usable misconfiguration check on this fabric — OPEN

Section 2.5’s guidance (“a VLAN configured here but not offered by the switch is a misconfiguration”) does not hold against these two switch models:

USW-Aggregation advertises only the PVID (VLAN 1) on both ports, while srv04fs and srv06hv carry tagged 200/400/1024 over them successfully.
TL-SE5226 advertises only VLANs flagged System-VLAN plus the PVID — port TG1/0/4 shows VLAN 10 while srv01hv also runs 200 and 300 over it, and TG1/0/20 shows VLAN 10 while srv05access also runs 200, 1024 and 2871.
Revision 2 adds the strongest case: TG1/0/18 advertises VLAN 1 only, while srv02gate runs six tagged VLANs over it (1, 10, 50, 200, 300, 1024), spanning Guest, IoT, DMZ and Secure Enclave. Taken literally the section 2.5 rule would flag five misconfigurations on that one port.

The apparent mismatches in section 2 are advertisement limitations, not proven misconfigurations. Confirmation would need the switch-side trunk configuration.

T-04 — Switch management shares production VLANs, not VLAN 2871 — OPEN

The “isolated management” VLAN 2871 terminates on exactly one host (srv05access 10.0.1.15). Neither switch is managed from it: TL-SE5226 is managed at 10.1.1.3 on VLAN 200 — the same VLAN as all general server traffic — and USW-Aggregation at 10.0.2.6 on VLAN 1.

Revision 2 makes this worse rather than better. VLAN 1 is now confirmed to reach the TL-SE5226 as a tagged VLAN on TG1/0/18, where srv02gate holds 10.0.2.3 in the same /24 as the USW’s management address and takes a DHCP default route via 10.0.2.1. So the switch management plane sits in a VLAN that (a) is not in Designated VLANs.md at all (T-10), (b) is the untagged/native VLAN on every observed access port, and (c) is directly addressable from a production host. Management traffic is not separated from the data plane, contrary to the intent implied by VLAN 2871’s existence.

T-05 — Divergent VLAN 200 default gateways — OPEN

srv02gate’s default route on VLAN 200 is 10.1.1.1 (static), while srv01hv, srv03mm, srv04fs, srv05access and srv06hv all use 10.1.1.3 (the TL-SE5226). Two distinct L3 next-hops are in use on the same VLAN; 10.1.1.1 was not identified from host data.

T-06 — TL-SE5226 is the sole L3 boundary across internal, DMZ and management — OPEN

The TL-SE5226 advertises the Router capability and is the VLAN 200 gateway. With srv02gate now placed on it, the same chassis is confirmed to trunk seven distinct VLANs to attached hosts: 1 (native/mgmt), 10 (IoT), 50 (Guest), 200 (Main internal), 300 (Secure Enclave), 1024 (DMZ) and 2871 (Management). Five of the nine designated VLANs — including both segments whose names assert isolation, Secure Enclave and Management — converge on one appliance that is also the L3 router between them. The segmentation boundary for most of the estate is a single device, and its own management address sits inside one of the VLANs it separates (T-04).

T-07 — Collector renders unnamed LLDP chassis as literal `id` (`collect_host_env.py`) — OPEN

srv01hv’s LLDP table renders tap105i0 / tap105i1 with the Switch column set to the literal string id. The raw JSON for those neighbours is chassis: {"id": {"type": "local", "value": "VM006-WIN"}} — a chassis object with no name key — so the renderer takes the first key (id) as the neighbour name and loses VM006-WIN. Any LLDP-speaking guest that advertises a local-type chassis ID is misrendered this way. Fix: when the chassis object has no name key, fall back to chassis.id.value.

Still present in the revision 2 srv01hv report (section 2.5, rows for tap105i0/tap105i1), and running as root did not change it — confirming it is a parser defect rather than a privilege artifact.

T-08 — srv01hv LLDP raw output truncated in the appendix — RESOLVED

Revision 1: the net.lldp appendix block for srv01hv ended with ... [truncated, 714 more lines], so the appendix could not be used to re-derive the topology independently of the rendered table.

Revision 2: the block is complete — roughly 25 KB of JSON covering all 17 neighbour entries, and the only remaining occurrence of the word “truncated” in the file is the boilerplate sentence in the appendix preamble. The srv02gate report is likewise untruncated. Both reports can now be re-derived from raw output alone. srv06hv (still revision 1, collected 12:12) has not been re-run and its larger blocks were not re-checked.

T-09 — Three guest interfaces bypass the per-VM firewall bridge — OPEN

Surfaced while drawing diagram 5.3. Proxmox normally inserts a per-VM filter bridge (fwbr<vmid>i<n> with an fwln/fwpr veth pair) between a guest tap and the target vmbr. Three taps are instead enslaved directly to a bridge, so no per-VM firewall is applied to them:

Host	Tap	Bridge	VLAN	Segment
srv01hv	`tap106i2`	`vmbr4nas`	400	storage `10.255.255.0/24`
srv06hv	`tap110i1`	`vmbr1plc`	200	main internal `10.1.0.0/20`
srv06hv	`tap104i2`	`vmbr2nas`	400	storage `10.255.255.0/24`

The same VMs’ other interfaces are filtered (fwbr106i0/i1, fwbr110i0, fwbr104i0/i1 all exist), so this is per-interface, not a host-wide setting — consistent with the firewall checkbox being left off on those specific NICs. tap110i1 is the notable one: it places VM110 unfiltered on VLAN 200, the main internal network. Verify against results/ external scans for the affected guest addresses before treating this as exploitable.

T-10 — VLAN 1 and the 214.1 double tag are live but not designated — OPEN

Designated VLANs.md lists nine VLANs (10, 50, 200, 204, 214, 300, 400, 1024, 2871). Two VLANs carrying real traffic are absent from it:

VLAN	Where	Evidence	Why it matters
1	srv02gate `eth0.1`	`10.0.2.3/24`, DHCP, default route via `10.0.2.1`; USW-Aggregation managed at `10.0.2.6`; PVID on all four observed access ports	Undocumented subnet that carries switch management and a working default route off-box
1 nested in 214	srv06hv `ens2f0.214.1`	802.1Q double tag, bridged to `hvintrav1` → `docker`	Undocumented QinQ path from container workloads onto the HV interconnect

VLAN 1 is not a stray: it has a DHCP server, a gateway, a switch management address and it is the native VLAN on every access port observed. It is load-bearing infrastructure that the design document does not acknowledge, which means no one has assigned it an intended security posture. The 214.1 stack is narrower but more surprising — it nests the native VLAN inside the hypervisor interconnect to reach a Docker bridge.

Neither is in the authorized scan scope, so no active verification was performed. Recommend either adding both to Designated VLANs.md with an explicit role, or confirming they should not exist.

T-11 — `Designated VLANs.md` lists VLAN 400 twice — OPEN

Lines 9 and 10 of the file are byte-identical:

| 400 | Network Storage | `10.255.255.0/24` |
| 400 | Network Storage | `10.255.255.0/24` |

Harmless as data — both rows agree, so no VLAN is ambiguously defined — but the file reads as ten designated VLANs when there are nine. Anything that counts rows rather than distinct VLAN IDs will be off by one. Worth deduplicating in the source; this report counts nine.

VM Host Audit Report

Mon, 31 Aug 2026 13:00:00 +0000

Network Topology — `vm*` Guests

Reconstructed VLAN attachment and exposed-service map for the seven vm* virtual machines.

Field	Value
Scope	`vm001-devel`, `vm002-docker`, `vm004-es`, `vm005-obj`, `vm010-db`, `vm011-jenkins`, `vm012-clickhouse`
Sources	`host-env-scan/hostenv_vm.md` — sections 1–6 and the `net.` appendix entries
Corroborating	`host-env-scan/hostenv_srv01hv_.md` / `hostenv_srv06hv_.md` (bridge topology + `fw.iptables`), `audit-report/NETWORK_TOPOLOGY.md` (`T-01`…`T-11`), `audit-report/SRV_HOST_SECURITY_AUDIT.md` (`S-01`…`S-15`), `Designated VLANs.md`
Method	Desk analysis of existing read-only collection. No scanning, no probing, no connection attempts and no configuration changes were performed for this document.
Collection window (UTC)	2026-08-25 23:10:48 → 23:14:23 (guests); hypervisors re-collected 2026-08-26 12:12 / 12:35
Finding prefix	`V-xx` (chosen to avoid collision with `F-xx` in `NETWORK_AUDIT_REPORT.md`, `T-xx` in `NETWORK_TOPOLOGY.md`, `S-xx`/`G-xx` in `SRV_HOST_SECURITY_AUDIT.md`)

Source report files:

Host	Report	Collected (UTC)	Privilege
vm002-docker	`hostenv_vm002-docker_20260825T231048Z.md`	23:10:52	sudo via password
vm001-devel	`hostenv_vm001-devel_20260825T231259Z.md`	23:13:02	sudo via password
vm004-es	`hostenv_vm004-es_20260825T231403Z.md`	23:14:14	sudo via password
vm005-obj	`hostenv_vm005-obj_20260825T231403Z.md`	23:14:16	sudo via password
vm010-db	`hostenv_vm010-db_20260825T231403Z.md`	23:14:19	sudo via password
vm011-jenkins	`hostenv_vm011-jenkins_20260825T231403Z.md`	23:14:21	sudo via password
vm012-clickhouse	`hostenv_vm012-clickhouse_20260825T231403Z.md`	23:14:23	sudo via password

The external view could not be cross-referenced. results/ and NETWORK_AUDIT_REPORT.md are root-owned and unreadable by the account running this analysis, so the usual AGENTS.md practice of reconciling the on-host view against the nmap view was not possible here. Everything below is the on-host view only. Where that view is insufficient to reach a conclusion, this document says so rather than guessing.

1. How VLAN membership was derived

No vm* guest has a single VLAN interface. All seven report VLAN interfaces: 0 in section 2.2. Every guest NIC is an untagged virtio_net device; the 802.1Q tag is applied on the hypervisor side, by the Proxmox bridge the guest’s tap is enslaved to. A guest therefore cannot report its own VLAN, and reading the guest report alone tells you nothing about segmentation.

VLAN membership below is established by two independent means, which agree everywhere they overlap:

Subnet match. Each guest address is matched against the subnets that the srv* hosts terminate on known VLAN interfaces (NETWORK_TOPOLOGY.md §3–4). 10.128.128.0/24 exists only on eth0p0.204/ens2f0.204, 10.1.0.0/20 only on *.200, 10.255.255.0/24 only on *.400. The mapping is unambiguous.
Bridge match. Each hypervisor’s vmbr* carries exactly one VLAN subinterface, so bridge identity fixes the VLAN: on srv01hv vmbr0vm→204, vmbr1plc→200, vmbr2iot→10, vmbr4nas→400; on srv06hv vmbr0vm→204, vmbr1plc→200, vmbr2nas→400, vmbr10ext→1024.

Consequence worth stating plainly: the guest’s own ens18/ens19/ens20 numbering is the only handle an operator has on which segment a NIC lands in, and that numbering is not self-describing. ens18 is VLAN 204 on six of the seven guests and VLAN 204-but-down on the seventh; ens19 is VLAN 200 on five guests, VLAN 400 on one, and unconfigured on one. This is finding V-07.

2. Guest inventory

Host	Role (inferred from listeners)	OS / kernel	vCPU / RAM	NICs	VLANs attached	Host firewall
vm001-devel	Development box, nginx TLS front end, Docker installed but idle	Debian 13 / 6.18.0-dirty	16 / 19.5 GiB	2	200, 204	none
vm002-docker	Docker Swarm node, 25 containers, Traefik ingress	Debian 13 / 6.12.74+deb13+1	32 / 62.8 GiB	2	200, 204	none
vm004-es	Elasticsearch + Kibana behind nginx	Debian 13 / 6.12.48	8 / 31.3 GiB	2	200, 204	none
vm005-obj	Garage S3 object store behind OpenResty; NFS client	Debian 13 / 6.12.48	8 / 15.6 GiB	3	200, 204, 400	none
vm010-db	MariaDB + Valkey	Debian 13 / 6.12.95	16 / 31.3 GiB	2	200, 204	none
vm011-jenkins	Jenkins behind nginx	Debian 13 / 6.12.95	8 / 15.6 GiB	2	200, 204	none
vm012-clickhouse	ClickHouse behind nginx, Vector metrics	Debian 13 / 6.12.101	8 / 7.8 GiB	3 (2 down)	200 (204, 400 cabled but unconfigured)	none

All seven are Debian 13 (trixie) KVM guests on QEMU Standard PC (i440FX + PIIX, 1996) with virtio_net NICs in the bc:24:11:* range — the Proxmox VE MAC prefix. firewalld is not installed on any of the seven; the collector reports firewalld zones (active) = 0 and Reachable through firewall = 0 for all of them, and every verdict in their section 5 is unknown — firewall data unavailable. See V-01 for what that means once the hypervisor ruleset is taken into account.

vm001-devel runs a locally built kernel (6.18.0-dirty) — the -dirty suffix means it was compiled from a modified, uncommitted tree. It is the only host in the estate not on a distribution kernel.

3. Per-guest VLAN → interface → address mapping

Gateway 10.1.1.3 is the TL-SE5226 switch (NETWORK_TOPOLOGY.md §1). 10.1.1.10 is srv02gate; 10.128.128.2 and 10.255.255.1 are both srv06hv, which runs a dotnet-based dns.service bound to every one of its VLAN addresses.

vm001-devel

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:0a:f0:87`	`10.128.128.7/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:9d:6a:f6`	`10.1.2.83/20`	DHCP
—	(Docker default bridge, DOWN)	`docker0`	—	`172.17.0.1/16`	static

Default route 10.1.1.3 via ens19. Resolver is the local systemd-resolved stub 127.0.0.53; search home hv.home vm.home. net.ipv4.ip_forward = 1.

vm002-docker

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:65:fe:9d`	`10.128.128.4/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:c3:8f:7d`	`10.1.2.73/20`	DHCP
—	Docker default bridge (DOWN)	`docker0`	—	`172.17.0.1/16`	static
—	Docker user bridge	`br-70f3ee0fb257`	—	`172.18.0.1/16`	static
—	Docker user bridge	`br-9e2a20ddf105`	—	`172.20.0.1/16`	static
—	Swarm gateway bridge	`docker_gwbridge`	—	`172.22.0.1/16`	static

Plus 40 veth interfaces. Default route 10.1.1.3 via ens19; nameservers 10.1.1.10 (srv02gate) and 10.128.128.2 (srv06hv). net.ipv4.ip_forward = 1. docker_gwbridge is flagged by the collector as having no on-disk configuration — correct, and expected for a runtime-managed bridge.

vm004-es

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:bb:51:3c`	`10.128.128.16/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:4f:71:23`	`10.1.2.70/20`	DHCP

Default route 10.1.1.3 via ens19; nameservers 10.1.1.10, 10.128.128.2.

vm005-obj — the only three-VLAN guest

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:11:e5:b4`	`10.128.128.13/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:f4:d4:4a`	`10.1.2.31/20`	DHCP
400	Network Storage	`ens20`	`bc:24:11:8f:2f:32`	`10.255.255.8/24`	DHCP

Default route 10.1.1.3 via ens19; connected route 10.255.255.0/24 via ens20. Nameservers in order 10.255.255.1 (srv06hv on VLAN 400), 10.128.128.2 (srv06hv on VLAN 204), 10.1.1.10 (srv02gate on VLAN 200); domain nas.home. This is the only vm* host that reaches the storage VLAN directly, and it is the only one that mounts srv04fs.nas.home:/share-mnts/objects.

vm010-db

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:ac:90:e5`	`10.128.128.17/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:1f:36:b8`	`10.1.2.71/20`	DHCP

Default route 10.1.1.3 via ens19; nameservers 10.128.128.2, 10.1.1.10. Uptime 38 d and NTP not synchronised — the only guest reporting clock drift, which matters for a database host and for log correlation.

vm011-jenkins

VLAN	Role	Interface	MAC	Address	Assignment
204	VMs Interconnect	`ens18`	`bc:24:11:4f:0d:8f`	`10.128.128.15/24`	DHCP
200	Main internal	`ens19`	`bc:24:11:cf:5a:59`	`10.1.2.68/20`	DHCP
—	(Docker default bridge, DOWN)	`docker0`	—	`172.17.0.1/16`	static

Default route 10.1.1.3 via ens19. Resolver is the systemd-resolved stub. net.ipv4.ip_forward = 1.

vm012-clickhouse — two NICs cabled but never configured

VLAN	Role	Interface	MAC	Address	State
204 (inferred)	VMs Interconnect	`ens18`	`bc:24:11:75:87:8b`	none	DOWN
400 (inferred)	Network Storage	`ens19`	`bc:24:11:03:42:ab`	none	DOWN
200	Main internal	`ens20`	`bc:24:11:e9:84:e3`	`10.1.2.78/20`	UP, DHCP

Default route 10.1.1.3 via ens20; single nameserver 10.1.1.10 (srv02gate); domain home, no search list. Only ens20 appears in /etc/network/interfaces.d/; the collector correctly flags ens18/ens19 as runtime-present but unconfigured. Their VLANs are inferred from the hypervisor placement deduced in §4, not observed — see V-08.

This is also the only guest whose FQDN is unqualified (vm012-clickhouse, not vm012-clickhouse.vm.home), consistent with its truncated resolver configuration.

4. Which hypervisor hosts which guest

No direct evidence links a vm* guest to a hypervisor: the guest MACs (bc:24:11:0a:f0:87 etc.) appear in neither hostenv_srv01hv_*.md nor hostenv_srv06hv_*.md. The only guest MACs the hypervisors observe are bc:24:11:96:d2:e9 / bc:24:11:9b:57:1a on srv01hv’s tap105i0/tap105i1, learned via LLDP from a guest that advertises itself as VM006-WIN — a Windows machine, not one of ours. The collector runs no ip neigh, no bridge fdb and no qm list, so there is no lookup table to consult.

Placement below is therefore deduced, from three constraints.

Constraint 1 — guest CPU model identifies the host CPU when cpu: host is set.

Hypervisor	Host CPU
srv01hv (Minisforum MS-A2)	AMD Ryzen 9 7940HX
srv06hv (Dell PowerEdge R740xd)	Intel Xeon Gold 6138

Three guests report Intel(R) Xeon(R) Gold 6138 CPU @ 2.00GHz — vm001-devel, vm002-docker and vm012-clickhouse — so those three are on srv06hv. The other four report QEMU Virtual CPU version 2.5+, the default kvm64 model, which masks the host and yields nothing. No guest reports an AMD Ryzen.

Constraint 2 — NIC count and per-index VLAN must match the hypervisor’s tap → bridge wiring. From the hypervisors’ §2.4 topology:

Node	VMID	net0	net1	net2
srv01hv	105	204	200	—
srv01hv	106	204	200	400 (tap direct to `vmbr4nas`, no `fwbr`)
srv01hv	107	10 (IoT)	204	200
srv06hv	100	204	200	—
srv06hv	101	204	200	—
srv06hv	102	204	400	200
srv06hv	103	204	200	—
srv06hv	104	204	200	400 (tap direct to `vmbr2nas`, no `fwbr`)
srv06hv	110	204	200 (tap direct to `vmbr1plc`, no `fwbr`)	—
srv06hv	112	204	200	—

Constraint 3 — VMID 105 is VM006-WIN, per the LLDP chassis TLV on srv01hv, so it is not a vm* guest. That leaves srv01hv with no free two-NIC slot.

Applying all three:

Guest	NIC profile	Placement	Confidence	Basis
vm001-devel	204, 200	srv06hv, one of VMID 100/101/103/110/112	node: high; VMID: unresolved	Xeon CPU
vm002-docker	204, 200	srv06hv, one of VMID 100/101/103/110/112	node: high; VMID: unresolved	Xeon CPU
vm004-es	204, 200	srv06hv, one of VMID 100/101/103/110/112	node: medium; VMID: unresolved	only free 2-NIC slots are on srv06hv
vm010-db	204, 200	srv06hv, one of VMID 100/101/103/110/112	node: medium; VMID: unresolved	as above
vm011-jenkins	204, 200	srv06hv, one of VMID 100/101/103/110/112	node: medium; VMID: unresolved	as above
vm012-clickhouse	204↓, 400↓, 200	srv06hv VMID 102	high	Xeon CPU + only 3-NIC profile whose net2 is VLAN 200 on that node
vm005-obj	204, 200, 400	srv01hv VMID 106 or srv06hv VMID 104	unresolved	profile matches both exactly; generic CPU gives no signal

The five two-NIC guests exactly fill srv06hv’s five two-NIC slots (100, 101, 103, 110, 112), which is a clean fit but is a pigeonhole argument: it holds only if all seven vm* guests are Proxmox guests of these two nodes (their bc:24:11 MAC prefix and Virtualisation: kvm support this, and no third Proxmox node exists in the estate) and if no other unscanned guest occupies one of those slots. Treat the node assignment as strong, the VMID assignment as open.

vm012-clickhouse = VMID 102 is the firmest single result here. It is the only guest with three NICs where net2 lands on VLAN 200; srv01hv’s only such profile is VMID 107, which would have reported an AMD CPU. It follows that vm012’s dead ens18 is on VLAN 204 and its dead ens19 is on VLAN 400, the storage segment — a live tap into storage on a NIC nobody has configured.

One determinate conclusion survives the vm005-obj ambiguity. Both candidate slots — srv01hv tap106i2 → vmbr4nas and srv06hv tap104i2 → vmbr2nas — are among the three taps that NETWORK_TOPOLOGY.md T-09 identified as enslaved directly to a bridge with no fwbr interposed. So whichever node it is on, vm005-obj’s VLAN 400 interface has no per-VM filter bridge. As V-01 shows, this turns out not to matter, because the filter bridges enforce nothing anyway.

A timing caveat: the guest reports were collected 2026-08-25 23:10–23:14 and the hypervisor reports 2026-08-26 12:12/12:35, roughly 13 hours later. A live migration or a start/stop in that window would invalidate the placement. Nothing in the data suggests one occurred, but nothing rules it out either.

5. Exposed ports and services

5.1 The governing rule

A guest socket bound to 0.0.0.0 or :: is reachable on every VLAN that guest has an interface in, with no per-VLAN distinction, because:

No vm* guest runs a host firewall (§2).
The hypervisors’ per-VM firewall chains are empty (V-01).

So the “Interfaces” column of each guest’s own section 5 is the answer, and its unknown — firewall data unavailable verdict resolves to reachable.

5.2 Reachable listeners, by guest

✔ = bound to a wildcard address and therefore reachable on that VLAN. Loopback-bound sockets are listed separately and are not reachable.

Guest	Proto/Port	Service	Process	VLAN 200	VLAN 204	VLAN 400
vm001-devel	tcp/22	SSH	`sshd`	✔	✔	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	—
	tcp/443	HTTPS	`nginx`	✔	✔	—
	tcp/5355, udp/5355	LLMNR	`systemd-resolved`	✔	✔	—
vm002-docker	tcp/22	SSH	`sshd`	✔	✔	—
	tcp/80, tcp/443	Traefik ingress	`docker-proxy`	✔	✔	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	—
	tcp/389	LDAP (cleartext)	`dockerd`	✔	✔	—
	tcp/1514	syslog / agent enrolment	`dockerd`	✔	✔	—
	tcp/1688	KMS emulator (`vlmcsd`)	`docker-proxy`	✔	✔	—
	tcp/2222	alternate SSH (container)	`dockerd`	✔	✔	—
	tcp/2377	Swarm cluster management	`dockerd`	✔	✔	—
	tcp/7946, udp/7946	Swarm gossip	`dockerd`	✔	✔	—
	udp/4789	VXLAN overlay	(kernel)	✔	✔	—
vm004-es	tcp/22	SSH	`sshd`	✔	✔	—
	tcp/80, tcp/443	reverse proxy	`nginx`	✔	✔	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	—
vm005-obj	tcp/22	SSH	`sshd`	✔	✔	✔
	tcp/80, tcp/443	reverse proxy	`openresty`	✔	✔	✔
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	✔
	tcp/36105, tcp/50647, udp/45714, udp/53735	NFS status monitor	`rpc.statd`	✔	✔	✔
	tcp/41877, tcp/46691, udp/44413, udp/46796	unattributed	—	✔	✔	✔
vm010-db	tcp/22	SSH	`sshd`	✔	✔	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	—
	tcp/3306	MariaDB	`mariadbd`	✔	✔	—
	tcp/6379	Valkey / Redis	`valkey-server`	✔	✔	—
vm011-jenkins	tcp/22	SSH	`sshd`	✔	✔	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	✔	—
	tcp/433	HTTPS on the wrong port, IPv6 only	`nginx`	✔	✔	—
	tcp/443	HTTPS, IPv4 only	`nginx`	✔	✔	—
	tcp/5355, udp/5355	LLMNR	`systemd-resolved`	✔	✔	—
	tcp/8080	Jenkins, direct	`java`	✔	✔	—
vm012-clickhouse	tcp/22	SSH	`sshd`	✔	—	—
	tcp/80, tcp/443	reverse proxy	`nginx`	✔	—	—
	tcp/111, udp/111	RPC portmapper	`rpcbind`	✔	—	—
	tcp/8123	ClickHouse HTTP	`clickhouse`	✔	—	—
	tcp/9000	ClickHouse native protocol	`clickhouse`	✔	—	—
	tcp/9004	ClickHouse MySQL wire protocol	`clickhouse`	✔	—	—
	tcp/9005	ClickHouse PostgreSQL wire protocol	`clickhouse`	✔	—	—
	tcp/9090	Vector metrics/API	`vector`	✔	—	—
	udp/43060	ClickHouse (secondary)	`clickhouse`	✔	—	—

5.3 Correctly confined listeners

These are bound to 127.0.0.1/::1 and are not reachable from any VLAN. They are listed because they show the pattern the estate does get right in places, which makes the wildcard binds above look like oversights rather than policy.

Guest	Loopback-only sockets
vm001-devel	tcp/8686 `vector`
vm002-docker	tcp/8686 `vector`
vm004-es	tcp/9200 + tcp/9300 `elasticsearch`, tcp/5601 `kibana`, tcp/8686 `vector`
vm005-obj	tcp/3900–3904 `garage`, udp/809 `rpc.statd`, tcp/8686 `vector`
vm010-db	tcp/8686 `vector`
vm011-jenkins	tcp/8686 `vector`
vm012-clickhouse	tcp/8686 `vector`

vm004-es and vm005-obj are the models: the data-plane service (Elasticsearch, Garage) listens only on loopback and a reverse proxy on 80/443 is the sole network entry point. vm010-db, vm011-jenkins and vm012-clickhouse run a reverse proxy and expose the backend directly alongside it, which defeats the proxy.

5.4 vm002-docker published container ports

25 containers publish ports. The collector correctly marks 80, 443 and 1688 as container-bypass: Docker’s DNAT rules are inserted ahead of any host firewall, so these are reachable regardless of host policy. On this guest there is no host policy to bypass in the first place.

Container	Image	Published
`traefik_traefik`	`traefik:v3.7`	`0.0.0.0:80→80`, `[::]:80→80`, `0.0.0.0:443→443`, `[::]:443→443`
`vlmcsd`	`vlmcsd`	`0.0.0.0:1688→1688`, `[::]:1688→1688`
`gitlab_gitlab`	`gitlab/gitlab-ce:18.10.1-ce.0`	22, 80, 443
`vaultwarden_vaultwarden`	`vaultwarden/server:latest`	80
`netbox_postgres`	`postgres:17-alpine`	5432
`netbox_redis`, `netbox_redis-cache`	`valkey/valkey:8.1-alpine`	6379
`wiki_wiki`, `wiki`	`ghcr.io/requarks/wiki:latest`	3000, 3443
`wiki_wiki-db`, `container-defs-wiki-db-1`	`postgres:15-alpine`	5432
`grafana_grafana`	`grafana/grafana:latest`	3000
`open-webui_open-webui`	`ghcr.io/open-webui/open-webui:main`	8080
`drawio_drawio`	`jgraph/drawio:latest`	8080, 8443
`striling-pdf_stirling-pdf`	`docker.stirlingpdf.com/stirlingtools/stirling-pdf:latest`	8080
`filestash_app`	`machines/filestash:latest`	8334
`polaris_app`	`registry.gitlab.com/connectical/container/polaris:latest`	5050
`vikunja_vikunja`	`vikunja/vikunja:2.3.0`	3456
`pairdrop_pairdrop`	`lscr.io/linuxserver/pairdrop:latest`	3000
`app-weighins`, `app-omnibackend`, `app-docviewer`	`registry.hub.home/apps/*`	3000
`app-vox-lunaris`, `app-archivium`, `app-bulletin`	`registry.hub.home/apps/*`	80

Only Traefik and vlmcsd publish to a host address; the rest expose ports on the Swarm overlay reached through Traefik.

The 25 container entries run 22 distinct images. 14 of those 22 are pinned to :latest — vaultwarden, wiki, grafana, drawio, filestash, polaris, pairdrop, stirling-pdf and all six registry.hub.home/apps/* images — and open-webui is pinned to the equally mutable :main. The running version of more than half the estate’s containerised services is therefore not recoverable from configuration, which blocks both patch verification and rollback. Only GitLab (18.10.1-ce.0), Traefik (v3.7), Vikunja (2.3.0), Postgres (17-alpine, 15-alpine) and Valkey (8.1-alpine) are pinned to something reproducible.

5.5 Storage dependencies

Guest	Mount	Transport	Served by
vm001-devel	`//nas.home/lxsky`, `//nas.home/home-tmpshare`, `//nas.home/home-public`	CIFS/SMB	srv04fs
vm001-devel, vm004-es, vm010-db, vm011-jenkins, vm012-clickhouse	`nas.home:/share-mnts/infra`	NFSv4	srv04fs
vm002-docker	`nas.home:/share-mnts/infra` → `/share-nas`	NFSv4	srv04fs
vm005-obj	`srv04fs.nas.home:/share-mnts/objects`	NFSv4	srv04fs, over VLAN 400
vm005-obj	`nas.home:/share-mnts/infra`	NFS	srv04fs

Every guest mounts from srv04fs. Only vm005-obj has a VLAN 400 interface; the other six reach the same file server through VLAN 200 and the TL-SE5226, so NFS and SMB traffic for six guests crosses the general-purpose internal VLAN rather than the segment designated for it. SRV_HOST_SECURITY_AUDIT.md already notes srv04fs has no host firewall and serves 2049/tcp and 445/tcp on all interfaces.

6. VLAN inventory as seen from the guests

Roles and designated ranges from Designated VLANs.md. “Audit scope” is the four VLANs authorized in TASK.md/AGENTS.md; the designation file is a network-design document, not an extension of scan authorization.

VLAN	Designated role	Designated range	Observed subnet	Scan scope	`vm*` addresses
200	Main internal	`10.1.1.0/20`	`10.1.0.0/20`	in scope	vm005-obj `.2.31`, vm011-jenkins `.2.68`, vm004-es `.2.70`, vm010-db `.2.71`, vm002-docker `.2.73`, vm012-clickhouse `.2.78`, vm001-devel `.2.83`
204	VMs Interconnect	`10.128.128.0/24`	`10.128.128.0/24`	not in scope	vm002-docker `.4`, vm001-devel `.7`, vm005-obj `.13`, vm011-jenkins `.15`, vm004-es `.16`, vm010-db `.17`
400	Network Storage	`10.255.255.0/24`	`10.255.255.0/24`	not in scope	vm005-obj `10.255.255.8`
10	IoT	`172.17.1.0/16`	`172.17.0.0/16`	in scope	none — but shadowed by `docker0` on three guests (`V-04`)

Every guest address falls inside its designated range. No guest is addressed outside the design.

A clear addressing convention emerges that is not written down anywhere in the repository: within VLAN 200’s 10.1.0.0/20, 10.1.1.0/24 holds infrastructure (srv02gate .10, srv01hv .11, srv03mm .12, srv04fs .13, srv05access .14, srv06hv .15, switch .3, unidentified gateway .1) and 10.1.2.0/24 holds guests (all seven vm*). Both are DHCP-assigned. The split is consistent across all thirteen collected hosts and is worth documenting before it is broken.

Only VLAN 200 of the guests’ three VLANs is inside the authorized scan scope. VLANs 204 and 400 appear here solely because they were read from on-host configuration; nothing was scanned in them.

7. Topology diagrams

7.1 Guest → hypervisor bridge → VLAN

Dashed edges are deduced placements (§4), solid edges are read directly from the guest’s own configuration.

flowchart LR subgraph HV6["srv06hv — Dell R740xd, Xeon Gold 6138"] B60["vmbr0vm
ens2f0.204
10.128.128.2"] B61["vmbr1plc
ens2f0.200
10.1.1.15"] B62["vmbr2nas
ens2f0.400
10.255.255.1"] end subgraph HV1["srv01hv — Minisforum MS-A2, Ryzen 9 7940HX"] B10["vmbr0vm
eth0p0.204
10.128.128.20"] B11["vmbr1plc
enp3s0.200
10.1.1.11"] B14["vmbr4nas
eth0p0.400
10.255.255.7"] end V1["vm001-devel
.128.7 / 10.1.2.83"] V2["vm002-docker
.128.4 / 10.1.2.73"] V4["vm004-es
.128.16 / 10.1.2.70"] V10["vm010-db
.128.17 / 10.1.2.71"] V11["vm011-jenkins
.128.15 / 10.1.2.68"] V12["vm012-clickhouse = VMID 102
10.1.2.78
ens18, ens19 DOWN"] V5["vm005-obj
.128.13 / 10.1.2.31 / 10.255.255.8
node UNRESOLVED"] V1 --- B60 V1 --- B61 V2 --- B60 V2 --- B61 V4 --- B60 V4 --- B61 V10 --- B60 V10 --- B61 V11 --- B60 V11 --- B61 V12 --- B61 V12 -.->|"ens18 DOWN"| B60 V12 -.->|"ens19 DOWN"| B62 V5 -.->|"if VMID 104"| B60 V5 -.->|"if VMID 104"| B61 V5 -.->|"if VMID 104, no fwbr"| B62 V5 -.->|"if VMID 106"| B10 V5 -.->|"if VMID 106"| B11 V5 -.->|"if VMID 106, no fwbr"| B14 classDef vm fill:#e8f0fe,stroke:#4285f4 classDef br fill:#fff4e5,stroke:#f9ab00 class V1,V2,V4,V5,V10,V11,V12 vm class B60,B61,B62,B10,B11,B14 br

7.2 Reachability — what listens where

flowchart TB SW["TL-SE5226
L3 gateway 10.1.1.3
routes VLAN 200"] subgraph VL200["VLAN 200 — Main internal, 10.1.0.0/20 — IN AUDIT SCOPE"] direction LR P200A["vm012-clickhouse 10.1.2.78
22, 80, 111, 443
8123, 9000, 9004, 9005, 9090"] P200B["vm010-db 10.1.2.71
22, 111, 3306, 6379"] P200C["vm002-docker 10.1.2.73
22, 80, 111, 389, 443
1514, 1688, 2222, 2377, 7946"] P200D["vm011-jenkins 10.1.2.68
22, 111, 433, 443, 5355, 8080"] P200E["vm001-devel 10.1.2.83
22, 111, 443, 5355"] P200F["vm004-es 10.1.2.70
22, 80, 111, 443"] P200G["vm005-obj 10.1.2.31
22, 80, 111, 443, statd"] end subgraph VL204["VLAN 204 — VMs Interconnect, 10.128.128.0/24 — not in scan scope"] direction LR P204["identical listener set on
10.128.128.4, .7, .13, .15, .16, .17
every wildcard bind repeats here"] end subgraph VL400["VLAN 400 — Network Storage, 10.255.255.0/24 — not in scan scope"] direction LR P400["vm005-obj 10.255.255.8
22, 80, 111, 443, statd
no per-VM filter bridge"] end NAS["srv04fs — dual-homed, no host firewall
10.1.1.13 on VLAN 200
10.255.255.9 on VLAN 400
NFS 2049, SMB 445 on all interfaces"] SW --> P200A SW --> P200B SW --> P200C SW --> P200D SW --> P200E SW --> P200F SW --> P200G P200B -.->|"second NIC"| P204 P200C -.->|"second NIC"| P204 P200D -.->|"second NIC"| P204 P200E -.->|"second NIC"| P204 P200F -.->|"second NIC"| P204 P200G -.->|"second NIC"| P204 P200G -.->|"third NIC"| P400 P200A -->|"NFS over VLAN 200"| NAS P200B -->|"NFS over VLAN 200"| NAS P200C -->|"NFS over VLAN 200"| NAS P200D -->|"NFS over VLAN 200"| NAS P200E -->|"NFS + CIFS over VLAN 200"| NAS P200F -->|"NFS over VLAN 200"| NAS P400 -->|"NFS over VLAN 400"| NAS classDef inscope fill:#fce8e6,stroke:#d93025 classDef outscope fill:#f1f3f4,stroke:#9aa0a6 classDef nas fill:#e6f4ea,stroke:#137333 class P200A,P200B,P200C,P200D,P200E,P200F,P200G inscope class P204,P400 outscope class NAS nas

Only vm005-obj reaches the file server over the segment designated for storage (V-10). The other six cross VLAN 200, and vm012-clickhouse has a VLAN 400 NIC that would carry it but is unconfigured (V-08).

8. Findings

ID	Summary	Bears on
`V-01`	Proxmox per-VM firewall chains are empty — no guest traffic is filtered anywhere	all guests
`V-02`	Database and cache services bound to all interfaces with no filtering	vm010-db, vm012-clickhouse
`V-03`	Every wildcard-bound guest service is duplicated onto VLAN 204	6 guests
`V-04`	`docker0`’s `172.17.0.0/16` shadows the entire IoT VLAN	vm001-devel, vm002-docker, vm011-jenkins
`V-05`	nginx listens on tcp/433 instead of 443 for IPv6	vm011-jenkins
`V-06`	Backend services exposed alongside the reverse proxy meant to front them	vm010-db, vm011-jenkins, vm012-clickhouse
`V-07`	VLAN membership is invisible from inside the guest	all guests
`V-08`	Two configured-but-dead NICs, one of them on the storage VLAN	vm012-clickhouse
`V-09`	Cleartext LDAP and Swarm control plane published to VLAN 200	vm002-docker
`V-10`	Six of seven guests carry NFS/SMB traffic across VLAN 200, bypassing VLAN 400	6 guests
`V-11`	Collector mislabels a bridge-bound socket as loopback-only	`collect_host_env.py`
`V-12`	Collector’s interface-stacking renderer misparents container `veth`s	`collect_host_env.py`
`V-13`	Unattributed listening sockets on vm005-obj	vm005-obj
`V-14`	vm010-db clock unsynchronised; vm001-devel runs a `-dirty` kernel	vm010-db, vm001-devel

V-01 — The Proxmox per-VM firewall enforces nothing

This is the finding that determines the severity of every other one, so it is stated first and with its evidence.

Both hypervisors build the full Proxmox filter scaffolding — a fwbr<vmid>i<n> bridge with an fwln/fwpr veth pair for almost every guest NIC. That scaffolding is what NETWORK_TOPOLOGY.md T-09 was reasoning about when it flagged three taps as “bypassing the per-VM firewall bridge”. Re-deriving from the raw fw.iptables appendix on both nodes shows the bridges are empty shells:

-A PVEFW-FORWARD -m conntrack --ctstate INVALID -j DROP
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PVEFW-FORWARD -m physdev --physdev-in fwln+ --physdev-is-bridged -j PVEFW-FWBR-IN
-A PVEFW-FORWARD -m physdev --physdev-out fwln+ --physdev-is-bridged -j PVEFW-FWBR-OUT
-A PVEFW-FWBR-IN -m conntrack --ctstate INVALID,NEW -j PVEFW-smurfs
-A PVEFW-FWBR-OUT

PVEFW-FWBR-IN contains one anti-smurf check and then returns. PVEFW-FWBR-OUT is completely empty. PVEFW-FORWARD has no terminating DROP for the physdev path, and the built-in FORWARD policy is ACCEPT on both nodes. A search of both appendices for any rule referencing a tap interface returns nothing — there are no per-VM rules at all. This is the signature of NIC-level “Firewall” checkboxes left enabled while the VM-level firewall is disabled: PVE creates the bridge, then installs no policy in it.

Three consequences:

Every guest listener bound to a wildcard address is reachable from every VLAN that guest is attached to. Combined with “no firewalld on any of the seven guests” (§2), there is no packet filter anywhere between a guest service and its VLAN.
T-09 is moot. Whether a tap has an fwbr in front of it or is enslaved directly to the vmbr makes no difference to what is filtered, because the fwbr path filters nothing. T-09 should be reclassified: the three unfiltered taps are not three exceptions in an otherwise-filtered estate, they are three cosmetic omissions in an entirely unfiltered one. That is a much larger problem stated much more quietly.
The hypervisors’ own GROUP-*-IN policies (SRV_HOST_SECURITY_AUDIT.md §2.1) are real and do protect the hosts — PVEFW-HOST-IN is populated and ends in a drop. Only the guest path is open. It is easy to look at the populated host chains and conclude the node is firewalled.

Verify before acting: the raw ruleset is a point-in-time capture and PVE regenerates these chains on configuration change. Confirm against /etc/pve/firewall/<vmid>.fw and /etc/pve/firewall/cluster.fw before treating this as settled.

V-02 — Databases and caches bound to all interfaces, unfiltered

Guest	Port	Service	Bind	Reachable from
vm010-db	tcp/3306	MariaDB	`0.0.0.0`	VLAN 200 `10.1.2.71`, VLAN 204 `10.128.128.17`
vm010-db	tcp/6379	Valkey (Redis)	`0.0.0.0` and `::`	VLAN 200, VLAN 204
vm012-clickhouse	tcp/8123	ClickHouse HTTP	`0.0.0.0`	VLAN 200 `10.1.2.78`
vm012-clickhouse	tcp/9000	ClickHouse native	`0.0.0.0`	VLAN 200
vm012-clickhouse	tcp/9004	ClickHouse MySQL wire	`0.0.0.0`	VLAN 200
vm012-clickhouse	tcp/9005	ClickHouse PostgreSQL wire	`0.0.0.0`	VLAN 200

Redis/Valkey is the sharpest of these: it has no authentication by default, and 6379 is bound on both IPv4 and IPv6 wildcards. ClickHouse exposing MySQL and PostgreSQL wire protocols alongside its native and HTTP interfaces means four independent authentication surfaces on one host, all on the main internal VLAN.

Not verified: whether these services require credentials. The collector reads socket state, not service configuration, and the engagement is read-only, so no connection was attempted. The exposure is confirmed; the exploitability is not.

Compare vm004-es, which runs Elasticsearch on 127.0.0.1:9200 behind nginx. The same pattern applied to vm010-db and vm012-clickhouse would close this finding.

V-03 — Every service is silently duplicated onto VLAN 204

VLAN 204 (VMs Interconnect) is a flat /24 shared by both hypervisors and six of the seven guests. Because no guest binds per-interface, every wildcard listener in §5.2 answers on the guest’s 10.128.128.x address as well as its 10.1.2.x one. MariaDB, Valkey, LDAP, the Swarm control plane and every SSH daemon are all present on VLAN 204.

This inverts the segment’s apparent purpose. A VLAN named “VMs Interconnect” reads as a low-value plumbing network; in practice it is a second, parallel, equally exposed copy of the entire guest attack surface — and unlike VLAN 200 it is outside the authorized scan scope, so no external scan has ever looked at it. The results/ external view, whatever it contains, cannot have covered this.

Anything with a foothold on VLAN 204 — including srv01hv and srv06hv themselves at 10.128.128.20 and 10.128.128.2 — reaches every guest service without crossing the TL-SE5226 or any L3 boundary at all.

V-04 — `docker0` shadows the entire IoT VLAN

Docker’s default bridge uses 172.17.0.1/16. The designated IoT range (VLAN 10) is 172.17.1.0/16, and every IoT interface in the estate is configured /16: srv02gate 172.17.1.2/16, srv05access 172.17.1.3/16, srv01hv 172.17.1.6/16. These are the same /16.

Three guests carry the resulting route in their main table:

Guest	Route	`docker0` state
vm001-devel	`172.17.0.0/16 dev docker0 proto kernel src 172.17.0.1`	DOWN
vm002-docker	`172.17.0.0/16 dev docker0 proto kernel src 172.17.0.1`	DOWN
vm011-jenkins	`172.17.0.0/16 dev docker0 proto kernel src 172.17.0.1`	DOWN

None of the three has a VLAN 10 interface, so absent the collision they would route IoT traffic via the default gateway 10.1.1.3. Instead the connected docker0 route wins on longest-prefix match and the packets go to a bridge that is administratively down — they are dropped. These three guests cannot reach any IoT host, and the failure mode is a silent blackhole, not a routing error.

The reverse direction is the part to watch. docker0 is DOWN on all three today. Start a container on any of them and Docker brings the bridge up and begins allocating container addresses out of 172.17.0.0/16 — the same space as live IoT devices. Address collisions between a container and an IoT host become possible, and on vm001-devel and vm011-jenkins systemd-resolved is already bound to 172.17.0.1:53, an address inside the IoT range.

The exposure is systemic rather than local: Docker’s default address pool is 172.16.0.0/12, which spans 172.16.0.0–172.31.255.255 and therefore contains both the IoT VLAN (172.17.x) and the DMZ VLAN 1024 (172.16.1.0/24, configured /16 on every host). vm002-docker has already allocated 172.18.0.1, 172.20.0.1 and 172.22.0.1 out of that pool. Those three do not currently collide, but nothing prevents the next network Docker creates from landing on 172.16.x or 172.17.x.

Remediation is configuration-only: set default-address-pools in /etc/docker/daemon.json to a range outside 172.16.0.0/12 — RFC 1918 space in 10.201.0.0/16 or similar — and set bip for docker0. Do this before the next container starts, not after.

V-05 — nginx listens on tcp/433 instead of 443 on IPv6

vm011-jenkins:

tcp | 443 | 0.0.0.0 | nginx <- IPv4, correct
tcp | 433 | :: | nginx <- IPv6, transposed digits

The IPv4 and IPv6 listeners are on different ports. This is a transposition in an nginx listen [::]:433 ... directive. Two effects: IPv6 clients get no HTTPS on the expected port, and tcp/433 is open estate-wide on both VLAN 200 and VLAN 204. An external scan would report 433/tcp as an unexpected open port with no obvious owner. Low severity, trivial fix, but it will keep costing analyst time until it is corrected.

V-06 — Backends exposed alongside the proxy that is supposed to front them

vm004-es and vm005-obj bind their data-plane services to loopback and expose only nginx/OpenResty on 80/443. Three guests do the opposite:

Guest	Proxy on	Backend also exposed
vm011-jenkins	tcp/443 (nginx)	tcp/8080 Jenkins, directly
vm012-clickhouse	tcp/80, tcp/443 (nginx)	tcp/8123, 9000, 9004, 9005 ClickHouse
vm010-db	(none)	tcp/3306, tcp/6379

Where a reverse proxy carries authentication, TLS termination, rate limiting or access logging, an exposed backend port bypasses all of it. Jenkins on 8080 is the clearest case: whatever the nginx vhost enforces in front of it is optional for any client that connects to 8080 directly.

V-07 — VLAN membership is invisible from inside the guest

None of the seven guests can determine which VLAN any of its NICs is in. There are no .1Q subinterfaces, no VLAN-aware bridge, and no naming convention that encodes the segment — the interfaces are ens18, ens19, ens20. Mapping requires the hypervisor’s bridge topology, which is a separate report collected from a separate host with separate credentials.

Practical consequences:

An operator on vm005-obj cannot tell that ens20 is the storage VLAN and ens19 is the main internal one without going and looking at srv06hv.
Per-interface bind decisions — exactly the control that would fix V-02 and V-03 — require knowledge the guest does not have locally.
The index-to-VLAN mapping is not even consistent across the estate: ens19 is VLAN 200 on five guests, VLAN 400 on vm005-obj, and VLAN 400-but-down on vm012-clickhouse.

The cheap fix is documentary: a systemd-networkd .link rename or a comment block in /etc/network/interfaces.d/ naming the VLAN for each device. It costs nothing and removes an entire class of bind-to-the-wrong-interface mistakes.

V-08 — vm012-clickhouse has a live storage-VLAN NIC that is unconfigured

ens18 and ens19 are present at runtime, carry Proxmox MACs, and appear in no on-disk network configuration — the collector flags them correctly. On the hypervisor side the corresponding taps exist and are bridged: per the §4 deduction (VMID 102 on srv06hv), ens18 lands on vmbr0vm (VLAN 204) and ens19 lands on vmbr2nas (VLAN 400, storage).

So the guest has a live layer-2 path into the storage segment on an interface nobody configured, nobody monitors, and which will not survive a reboot as anything other than an unconfigured device. It carries no IP today, so there is no reachability today — but the tap is bridged, the segment is one dhclient invocation away, and any process on the guest that can bring an interface up can reach VLAN 400 without crossing a router.

The VLAN attribution rests on the §4 placement deduction, which is high-confidence but not directly observed. Confirm from /etc/pve/qemu-server/102.conf on srv06hv, which will state the bridge and VLAN tag for net0/net1/net2 explicitly. If the guest genuinely needs neither NIC, remove them from the VM configuration rather than leaving them down.

V-09 — Cleartext LDAP and the Swarm control plane on VLAN 200

vm002-docker publishes, on both VLAN 200 and VLAN 204:

Port	What it is	Concern
tcp/389	LDAP, cleartext	Directory bind credentials cross the wire unprotected; no 636/LDAPS listener accompanies it
tcp/2377	Docker Swarm cluster management	Control-plane port; joining a manager grants orchestration over every service on the swarm
tcp/7946 tcp+udp	Swarm node gossip	Cluster membership
udp/4789	VXLAN overlay data plane	Carries all inter-service overlay traffic
tcp/2222	Alternate SSH, probably GitLab’s (it publishes 22/tcp internally)	A second SSH surface with credentials separate from the host’s own tcp/22
tcp/1514	Syslog / agent enrolment, service not identified	Ports in this role are commonly unauthenticated ingest
tcp/1688	KMS emulator (`vlmcsd`)	Unlicensed activation service, published to the internal VLAN

Swarm’s control plane is designed to run on a trusted management network. Here 2377, 7946 and 4789 are all reachable from the general-purpose internal VLAN and, per V-03, from VLAN 204 as well, with no filtering at either the guest or the hypervisor. vlmcsd is a separate matter — a KMS emulator is an unlicensed activation service and is worth raising with the system owner independently of any security question.

Caveat on attribution. Ports 389, 1514, 2222, 2377 and 7946 are attributed by ss to dockerd itself, not to a named container, because Swarm-published ports are opened by the daemon rather than by a docker-proxy child. The docker runtime table in §5.4 does not list 389, 1514 or 2222 against any container, so which services back those three was not established. The port numbers are observed facts; the service names above are inference from convention. Run docker service ls / docker service inspect to identify them before changing anything.

V-10 — Storage traffic for six guests crosses VLAN 200

VLAN 400 exists and is designated “Network Storage”. Exactly one guest, vm005-obj, has an interface in it. The other six mount NFSv4 (and, on vm001-devel, three CIFS shares) from the same file server over VLAN 200, routed through the TL-SE5226.

The storage VLAN therefore carries a minority of the estate’s storage traffic, while the general-purpose internal VLAN carries the majority — including SMB sessions from vm001-devel. Since srv04fs runs no host firewall and serves 2049/tcp and 445/tcp on all interfaces (SRV_HOST_SECURITY_AUDIT.md), the file server’s full NFS and SMB surface is reachable from VLAN 200 regardless.

Either give the six guests a VLAN 400 NIC and pin the mounts to it, or accept that VLAN 400 is a partial deployment and document it as such. The current state gets the operational cost of a separate storage VLAN with little of its benefit.

V-11 — Collector reports a bridge-bound socket as “loopback only”

collect_host_env.py defect. On vm001-devel and vm011-jenkins, section 5 renders:

| tcp | 53 | systemd-resolved.service | 127.0.0.53, 127.0.0.54, 172.17.0.1 | docker0 | - | not-exposed | bound to loopback only |

172.17.0.1 is docker0, not loopback. The exposure analysis aggregates all bind addresses for a (proto, port, service) tuple into one row and then derives a single verdict; because two of the three addresses are loopback, the row is labelled not-exposed — bound to loopback only, and the non-loopback bind disappears from the finding.

The same table’s own “Interfaces” column already says docker0, contradicting the verdict two columns to the right. The udp/53 row for the identical bind set is labelled unknown rather than not-exposed, so the two are not even self-consistent.

Here the practical impact is nil — docker0 is DOWN on both guests — but the logic is wrong in general: any service bound to both loopback and a live interface will be reported as unexposed. Fix: derive the verdict per bind address and emit the worst case, or split the row.

V-12 — Collector misparents container `veth`s in the stacking tree

collect_host_env.py defect, visible in vm002-docker section 2.4. Three veths are printed twice — once under their real bridge master, and again as children of the physical NIC:

br-70f3ee0fb257 ...
`-- vethfa8ae03
br-9e2a20ddf105 ...
|-- veth07e013b
`-- veth8a37a0f
...
ens18 [physical, virtio_net, -1Mb/s, UP] 10.128.128.4/24
|-- veth07e013b
|-- veth8a37a0f
`-- vethfa8ae03

Section 2.3 gives their correct masters (br-70f3ee0fb257, br-9e2a20ddf105), so the data is right and only the tree renderer is wrong. The likely cause is resolving iflink rather than master: for a veth whose peer lives in a container network namespace, the peer ifindex can collide with an ifindex in the host namespace — here ens18 — and the renderer attaches it there.

The consequence for an auditor is a false picture of guest-side segmentation: read literally, the tree says three container interfaces are enslaved directly to the VLAN 204 NIC. They are not. Fix: build the tree from master, and ignore iflink when link_netnsid is set.

V-13 — Four unattributed listening sockets on vm005-obj

Proto	Port	Bind	Process
tcp	41877	`::`	(none resolved)
tcp	46691	`0.0.0.0`	(none resolved)
udp	44413	`0.0.0.0`	(none resolved)
udp	46796	`::`	(none resolved)

All four are in the ephemeral range and sit alongside four sockets that were attributed to rpc.statd (36105, 50647, 45714, 53735). The most likely explanation is kernel-side NFS — lockd and the NFSv4 callback channel — which have no userspace PID for ss -p to report, which is exactly why the collector leaves them blank. That is consistent with vm005-obj being the estate’s only NFS-heavy guest.

This is a hypothesis, not a conclusion. rpcinfo -p on the host would settle it, and is read-only. Until then these are four open ports on three VLANs with no identified owner, and they should not be dismissed as “probably NFS” in the deliverable. Note also that they are dynamically allocated, so an external scan from a different day would see different port numbers — which is worth flagging to anyone diffing scan results.

V-14 — Clock and kernel hygiene

Two unrelated items, grouped because both are single-host and low severity.

vm010-db reports NTP synchronised: no after 38 days of uptime. It is the only host among all thirteen collected with unsynchronised time. On a database host this affects transaction timestamps, replication ordering if replication is ever configured, certificate validity checks and — most relevant to this engagement — the ability to correlate its logs with anything else during an incident.

vm001-devel runs kernel 6.18.0-dirty. The -dirty suffix is emitted by the kernel build system when the source tree contains uncommitted modifications, so this is a locally built kernel from a tree whose exact contents are not recoverable. It is the only non-distribution kernel in the estate. Consequences: it is outside Debian’s security update path, 6.18.0 is newer than every other kernel here (the rest are 6.12.x), and the modifications cannot be reviewed. For a host named devel this may well be deliberate; it should nonetheless be recorded, and the machine should not be treated as having the same patch posture as the others.

9. What would resolve the open questions

Each of these is read-only and within the engagement’s constraints.

Question	Command	Resolves
Which node and VMID is vm005-obj?	`qm list` on srv01hv and srv06hv	§4 ambiguity
Confirm every guest’s VLAN tags	`cat /etc/pve/qemu-server/*.conf` on both nodes	§4, `V-08`
Is the guest firewall genuinely off?	`cat /etc/pve/firewall/cluster.fw /etc/pve/firewall/*.fw`	`V-01`
What are vm005-obj’s unattributed ports?	`rpcinfo -p` on vm005-obj	`V-13`
What backs vm002-docker’s tcp/389?	`docker service ls`, `docker service inspect`	`V-09`
Do the exposed databases require credentials?	Service config review — not a connection attempt	`V-02`
Does the external view agree?	Read access to `results/` and `NETWORK_AUDIT_REPORT.md`	whole document

The last one is the most important. This report is built entirely from the on-host view; AGENTS.md is explicit that the on-host and external views are complementary and that neither should be trusted alone. Until results/ can be read, the reachability claims in §5 are derived from ruleset analysis rather than confirmed by observation. Note that VLANs 204 and 400 are outside the authorized scan scope, so for V-03 and V-10 no external corroboration can exist at all — those must stand or fall on the configuration evidence presented here.

Month 1 Summary

Sat, 27 Jun 2026 15:17:51 +0000

Month 1 of learning, covering topic 1-5 from the book Learn Latin from the Romans.

Vocabulary & Things to Memorise

Nouns

agricola, -ae, (m.) - farmer
dea, -ae, (f.) - goddess
deus, -i, (m.) - god
poeta, -ae, (m.) - poet
puella, -ae, (f.) - girl
amicus, -i, (m.) - friend
equus, -i, (m.) - horse
servus, -i, (m.) - slave
oppidum, -i, (n.) - town
bellum, -i, (n.) - war
verbum, -i, (n.) - word
consilium, -i, (n.) - advice, plan
epistula, -ae, (f.) - letter
pecunia, -ae, (f.) - money

Adjectives

bonus, -a, -um - good
magnus, -a, -um - big
meus, -a, -um - my
tuus, -a, -um - your (singular)
novus, -a, -um - new

Others

-ne, suffix - mark the question
et, conjunction - and
non, adverb - not

Verbs

I	II	III	IV	Translation
curro	currere	cucurri	cursum	run
duco	ducere	duxi	ductum	lead
emo	emere	emi	emptum	buy
lego	legere	legi	lectum	read
mitto	mittere	misi	missum	send
pono	ponere	posui	positum	put
peto	petere	petivi	petitum	seek
rego	regere	rexi	rectum	rule
scribo	scribere	scripsi	scriptum	write
vinco	vincere	vici	victum	conquer
sum	esse	fui	futurus	be

Irregular - sum

	Present	Future	Perfect
1s	sum	ero	fui
2s	es	eris	fuisti
3s	est	erit	fuit
1p	sumus	erimus	fuimus
2p	estis	eritis	fuistis
3p	sunt	erunt	fuerunt

Declension

Declension I ( -a )

(-a)	sg.	pl.
Nom.	-a	-ae
Acc.	-am	-as
Voc.	-a	-ae
Gen.	-ae	-arum

Declension II ( -us, -um )

(-us)	sg.	pl.
Nom.	-us	-i
Acc.	-um	-os
Voc.	-e	-i
Gen.	-i	-orum

(-um)	sg.	pl.
Nom.	-um	-a
Acc.	-um	-a
Voc.	-um	-a
Gen.	-i	-orum

Conjugations of Active Indicative Group III Verbs

(-ere)	Present	Future	Perfect
1s	-o	-am	-i
2s	-is	-es	-isti
3s	-it	-et	-it
1p	-imus	-emus	-imus
2p	-tis	-etis	-istis
3p	-unt	-ent	-erunt
pp.	I	I	III

pp. : Principle Part to get stem from

Grammar & Concepts

Nouns and Declension

Each noun and its variations can be defined on 3 dimensional axes:

Genders: Masculine, Feminine and Netur
Quantity: Singular, Plural
Cases: Nominative, Accusative, Vocative, Genitive (4 of 6 cases covered in this month)

Each noun can have only one gender.

Based on genitive suffix, a noun can be classified into different declension, and each declension has their own rules of “declening” thing across the rest of dimensions.

Specifically, each declension define it’s own subspace spanned by Quantity and Cases

The first two declensions and their rules:

Declension I ( -a )

Most of the noun in this group is feminine.

(-a)	sg.	pl.
Nom.	-a	-ae
Acc.	-am	-as
Voc.	-a	-ae
Gen.	-ae	-arum

Declension II ( -us, -um )

Most of the noun in this group is masculine or netur.

(-us)	sg.	pl.
Nom.	-us	-i
Acc.	-um	-os
Voc.	-e	-i
Gen.	-i	-orum

(-um)	sg.	pl.
Nom.	-um	-a
Acc.	-um	-a
Voc.	-um	-a
Gen.	-i	-orum

Cases

Cases indicate the grammatic role of the noun:

Nominative: Denote the subject that initiate the action.
Accusative: Denote the direct reciever of the action.
Vocative: Calling of the object.
Genitive: Denote the possession relationship, that the noun (object) is the owner of something else.

Adjectives

An adjective is used to describe the noun.

The adjective and its noun must be agreed in case, gender and quantity

For this reason, adjectives have variants of all three genders.

Verbs, Tense and Conjugation

Each verb and its variations can be defined in a 4 dimensional configuration space, spanned by the axes:

Pronouns:
- first person singular (1s)
- second person singular (2s)
- third person singular (3s)
- first person plural (1p)
- second person plural (2p)
- third person plural (3p)
Tenses
- Present (Pr)
- Future (Fu)
- Perfect (Pe)
- Imperfect (Im) (Not Covered)
- Pluperfect (Pp) (Not Covered)
- Future Perfect (Fp) (Not Covered)
Voice:
- Active
- Passive (Not Covered)
Form & Mood:
- Indicative
- Subjunctive (Not Covered)
- Imperative (Not Covered)
- Indefinitive

With three additional forms for verb-noun, verb-adjectives which will be covered in later topics.

Conjugation of Verbs

Similar to noun’s declension, conjugation of the verb defines the how suffix changes as it moves through the “configuration space”.

The indefinitive form of the verb gives conjugation group of the verb.

The key of any conjugation rules is to identify the stem and the list of compatible suffixes.

Principle Parts - Giving the Desired Stem

Each verb has four principle parts.

From these parts, all the variations in the configuration space can be dervied by attaching compatible suffixes.

The four principle parts (pp):

I Present Active First Person Singular Indicative (1sPrAInd)
II Indefinitive
III Perfect Active First Person Singular Indicative (1sPeAInd)
IV Supine

Suffixes - Determining the Variants

Suffixes varies from dimensions to dimensions.

Each suffix must be paired with specific stem for a valid conjugation.

Current we have learned 3 tense and 6 pronouns of active indicative, conjugation III.

(-ere)	Present	Future	Perfect
1s	-o	-am	-i
2s	-is	-es	-isti
3s	-it	-et	-it
1p	-imus	-emus	-imus
2p	-tis	-etis	-istis
3p	-unt	-ent	-erunt
pp.	I	I	III

Note: There are some cases where two supposely different tense share same suffix and stem, for example legit (3sPr) and legit (3sPe), in this case, the disambigious will be the length of the first vowel of the stem:

short vowel for present tense
long vowel for perfect tense

Tense

We currently only covered three tenses:

Present: The action that is happening at the moment. It capture these two meaning in English: a present fact (I eat) or an action is happening now (I am eating)
Future: Action that will happen some point in the future, it is a destined. Same as the one in English.
Perfect: Action that happened in the past, Same as the one in English.

NOTE

For perfect sense, it is not clear whether the action is still ongoing or has been completed. for this you will need to use other tense to clarify (namely: imperfect or pluperfect). More on this in later topics.

Sentence Composition

Latin has flexible word order when composing a sentence.

Generally speaking, the most common word order is the Subject-Object-Verb (SOV) form.

For example, Verba scribo (Words I am writing $\rightarrow$ I am writing words).

Forming the Question

For forming a question. Put the verb as the first word of the sentence and appened suffix -ne to it.

For example: Scripsitne verba (Did he/she write words)?

Vox Pulveris

Month 2 - Vocabulary List

Nouns

Adjectives

Prepositions

Conjunctions

Adverbs

Numerals

Verbs

Irregulars

eō, ire, iī/īvī, itum - to go

hic, haec, hoc - this / these

ille, illa, illud - that / those

ego, tū, nōs, vōs - I, You / We, You

is, ea, id, ei, eae, ea - He, She, It / They

Compound

Baremetal Host Audit Report

Host Security Audit — srv* Machines

1. Host inventory

2. Attack surface: what is actually reachable, per VLAN

2.1 srv01hv — PVE firewall, verified from fw.iptables

2.2 srv06hv — same cluster ruleset

2.3 srv02gate — firewalld, verified from fw.nft filter_IN_public_allow

2.4 srv05access — firewalld, zones verified from fw.active_zones + fw.zones_permanent

2.5 srv03mm and srv04fs — no host firewall

3. Findings

S-01 — No host firewall on srv03mm and srv04fs — High

S-02 — srv02gate’s public zone spans six VLANs including guest and IoT — High

S-03 — Single-host concentration of DNS, DHCP, RADIUS and ingress — High

S-04 — srv05access is the estate’s best pivot, and accepts SSH from DMZ and IoT — Medium

S-05 — Unauthenticated monitoring surfaces — Medium

S-06 — Kernel network hardening is off estate-wide — Medium

S-07 — Proxmox cluster ruleset contains stale interface rules and over-broad groups — Medium

S-08 — Guest and container interfaces bypassing the PVE bridge firewall — Medium

S-09 — The most privileged access path on both hypervisors is unverified — Medium

S-10 — Unauthenticated and legacy file services on srv04fs — Medium

S-11 — Configuration-integrity defects — Low

S-12 — Extra network daemons on the hypervisors — Low

S-13 — Tunnelling software on both cross-VLAN hosts — Low

S-14 — Patch cadence and OS drift — Low

S-15 — Collector drops the default zone, producing false filtered verdicts — Low (tooling)

4. Firewall configuration issues, by host

5. Recommended actions

P1 — do first

P2 — next

P3 — hygiene and hardening

6. Recommended firewall configuration

6.1 srv04fs and srv03mm — from nothing to default-deny

6.2 srv02gate — split public by trust level

6.3 srv05access — tighten the choke host

6.4 srv01hv and srv06hv — Proxmox security groups

6.5 Estate-wide sysctl baseline

7. Evidence gaps

8. Method note

Network Topology Report

Network Topology — srv* Hosts

1. Switches

2. Host → switch → port → VLAN

Interfaces with no switch attachment (carrier down)

3. Per-host VLAN → interface → address mapping

srv01hv (Proxmox, dual-homed 2.5G + 10G)

srv06hv (Proxmox, single 10G uplink)

srv02gate (router-ish Pi, 6 VLANs on one 1G link)

srv03mm

srv04fs

srv05access (choke / multihomed audit host)

4. VLAN inventory

5. Topology diagrams

5.1 Physical link layer — switch, port, trunked VLANs

5.2 VLAN membership

5.3 Hypervisor bridge fan-out

6. Gaps and anomalies

T-01 — srv01hv eth0p0 upstream switch/port unresolved — OPEN

T-02 — srv02gate returned an empty LLDP table — RESOLVED

T-03 — “VLANs offered” is not a usable misconfiguration check on this fabric — OPEN

T-04 — Switch management shares production VLANs, not VLAN 2871 — OPEN

T-05 — Divergent VLAN 200 default gateways — OPEN

T-06 — TL-SE5226 is the sole L3 boundary across internal, DMZ and management — OPEN

T-07 — Collector renders unnamed LLDP chassis as literal id (collect_host_env.py) — OPEN

T-08 — srv01hv LLDP raw output truncated in the appendix — RESOLVED

Host Security Audit — `srv*` Machines

2.1 srv01hv — PVE firewall, verified from `fw.iptables`

2.3 srv02gate — firewalld, verified from `fw.nft` `filter_IN_public_allow`

2.4 srv05access — firewalld, zones verified from `fw.active_zones` + `fw.zones_permanent`

S-02 — srv02gate’s `public` zone spans six VLANs including guest and IoT — High

S-15 — Collector drops the default zone, producing false `filtered` verdicts — Low (tooling)

6.2 srv02gate — split `public` by trust level

Network Topology — `srv*` Hosts

T-01 — srv01hv `eth0p0` upstream switch/port unresolved — OPEN

T-07 — Collector renders unnamed LLDP chassis as literal `id` (`collect_host_env.py`) — OPEN

T-11 — `Designated VLANs.md` lists VLAN 400 twice — OPEN

Network Topology — `vm*` Guests

V-04 — `docker0` shadows the entire IoT VLAN

V-12 — Collector misparents container `veth`s in the stacking tree