Skip to content

docs: describe what the Hicks interface enforces, not what it did (#228) - #272

Merged
Gerrrt merged 2 commits into
mainfrom
gerrrt/network-md-hicks-reach
Sep 4, 2026
Merged

docs: describe what the Hicks interface enforces, not what it did (#228)#272
Gerrrt merged 2 commits into
mainfrom
gerrrt/network-md-hicks-reach

Conversation

@Gerrrt

@Gerrrt Gerrrt commented Sep 4, 2026

Copy link
Copy Markdown
Owner

Part of #228 — the description half. The posture decision (whether Hicks
should reach ImaginationLAN entire) is deliberately not made here.

Note

Was stacked on #269, because
that PR is where roadmap.md's #228 entry lives and this change makes one of
its sentences untrue. #269 is merged and this branch is rebased onto main;
the diff is now this change alone.

What the firewall actually enforces

Read on morpheus 2026-09-04 — pfctl -sr and pfctl -vsr, interface tables
resolved with pfctl -t OPT1__NETWORK -T show. The Hicks tab (igc0.50), in
order: ten host- and port-scoped passes into Winterfell, a pass to the switch's
web UI, the ImaginationLAN pass, then blocks — including a logged Block access
to Winterfell
(id 1788320848) and a logged Block access to LAN (id
1788320922) — and only then Allow internet.

Nine of the ten passes and both blocks were created 2026-09-02, the day
after ADR-0013 was committed. The block has taken 22 packets; of the passes
above it, only Allow NTP and Allow HTTP to Mjolnir are still at zero
(834,283 packets through Allow SSH to Winterfell alone).

What was wrong

network.md's Reaches column said Internet, 99, 30, and its Hicks notes
said "only specific hosts on this VLAN may reach Winterfell, and only on
management ports". That had the narrowing backwards in both halves — every
pass is sourced from <OPT2__NETWORK>, the segment, not from named hosts, and
the restriction is by destination and port. The ten passes are now enumerated as
a table where that claim used to be.

Two things the read turned up

The corporate-laptop note is not a control. network.md said they "have no
management access". No alias holds 10.0.50.69 or 10.0.50.70 (pfctl -sT
shows no such table) and no rule names them, so they carry exactly the access
every other Hicks device has. It is now written as the policy it is.

The Prometheus and Loki ingest ports are no longer reachable from Hicks.
security.md said a workstation there "can write to the metric and log stores
without a credential" — Block access to Winterfell now drops 9090 and
3100, and Hicks reaches 10.0.99.20 on 3000 only. What remains in that set
is a host already on Winterfell, and 10.0.30.110's explicit pass for
Saruman's Alloy agent. The residual narrowed, by a firewall change nobody
recorded. #182 still owns closing it properly: a control resting on one
un-reviewed rule ordering is not authentication.

Not changed

ImaginationLAN is still reached entire, on every protocol and port — no rule
blocks it and the catch-all is reached. That is #228's decision and is left
open. Allow Hicks access to ImaginationLAN now sits on the Hicks
interface, where it matches at last and grants nothing the catch-all was not
already granting (ADR-0013 found it on the wrong interface; that is fixed on the
firewall).

Per ADR-0001, ADR-0013 and ADR-0016 are left as written. Both describe the
ruleset of 2026-09-01, and every present-tense document that cites them now says
so.

Files

  • docs/network.mdReaches column + new [^hicks] footnote, the ten passes
    as a table, the corporate-laptop note, the ingest-port note, the
    ImaginationLAN note, the switch-LAN note, and the Winterfell section's
    admin-UI line
  • docs/security.md — the Segmentation section split into the half that was
    narrowed and the half that was not, and the ingest-port residual rewritten
    around who "anything" now is
  • SECURITY.md — the same residual row
  • README.md — points at network.md for current state and at ADR-0013 for the
    method and the date it read
  • docs/roadmap.md — drops the "network.md still says" line this change makes
    untrue

make validate passes (2 skips: not the deployment host).

🤖 Generated with Claude Code

Copilot AI lite review requested due to automatic review settings September 4, 2026 05:43

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

A few newly introduced doc statements are internally inconsistent/ambiguous (notably rule-grant wording and incomplete host:port notation) and should be corrected for accuracy.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates documentation to reflect the currently enforced pfSense posture for the Hicks interface (VLAN 50), distinguishing what ADR-0013 described on 2026-09-01 from what the firewall enforces after the 2026-09-02 narrowing, and clarifying the residual around Prometheus/Loki ingest exposure.

Changes:

  • Updates Hicks’ documented reachability: Winterfell access is now described as destination/port-scoped passes above an enforcing block; ImaginationLAN remains broadly reachable pending #228.
  • Rewrites the Prometheus/Loki ingest residual in SECURITY.md and docs/security.md to match who can still reach 9090/3100 after the narrowing.
  • Adjusts README/roadmap language to point readers at docs/network.md for current state and ADR-0013 for method/historical read.
File summaries
File Description
SECURITY.md Updates the Prometheus/Loki unauthenticated-ingest residual to match current reachability.
README.md Repoints “current state” documentation to docs/network.md and scopes ADR-0013 to its read date.
docs/security.md Splits segmentation narrative into what’s still open (ImaginationLAN) vs what was narrowed (Winterfell) and updates ingest residual description.
docs/roadmap.md Removes/rewrites now-stale phrasing about which documents still describe the wider state.
docs/network.md Updates Hicks “Reaches” entry and adds detailed notes/footnote describing the narrowed management access list.
Review details
  • Files reviewed: 5/5 changed files
  • Comments generated: 4
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread SECURITY.md Outdated
Comment thread docs/network.md Outdated
Comment thread docs/security.md
Comment thread docs/security.md Outdated
Base automatically changed from gerrrt/adr-0008-tiers-firewall-3e5ef9 to main September 4, 2026 13:29
The Hicks tab was narrowed on 2026-09-02 and nothing in the repository
recorded it. Read on morpheus 2026-09-04, pfctl -sr and -vsr with the
interface tables resolved: ten host- and port-scoped passes into
Winterfell sit above a logged Block access to Winterfell, and everything
else from 50 to 99 is dropped. The block has taken 22 packets; of the
passes above it, only Allow NTP and Allow HTTP to Mjolnir are at zero.

network.md said "Internet, 99, 30" in the Reaches column, and its Hicks
notes said "only specific hosts on this VLAN may reach Winterfell, and
only on management ports". That had the narrowing backwards in both
halves: every pass is sourced from the segment, not from named hosts, and
the restriction is by destination and port. Both are corrected, and the
ten passes are enumerated where the claim used to be.

Two further things that read against the ruleset:

- The note saying corporate laptops "have no management access" is not
  enforced by anything. No alias holds 10.0.50.69 or 10.0.50.70 and no
  rule names them, so they carry exactly the access every other Hicks
  device has. It is now written as the policy it is rather than as a
  control.
- The Prometheus and Loki ingest ports are no longer reachable from
  Hicks. security.md said a workstation there could write to the metric
  and log stores without a credential; Block access to Winterfell drops
  9090 and 3100, and what remains in that set is a host already on
  Winterfell and 10.0.30.110's explicit pass. #182 still owns closing it
  properly — a control that rests on one un-reviewed rule ordering is not
  authentication.

ImaginationLAN is untouched and is still reached entire, on every
protocol and port, because no rule blocks it and the catch-all is
reached. That is #228's posture decision and is not made here. Allow
Hicks access to ImaginationLAN now sits on the Hicks interface, where it
matches at last and grants nothing the catch-all was not already
granting.

Per ADR-0001, ADR-0013 and ADR-0016 are left as written; both describe
the ruleset of 2026-09-01 and both now say so where they are cited.
README.md and SECURITY.md restated the same claim and are corrected with
them, and roadmap.md's #228 entry drops the line about network.md being
wrong, which this change makes untrue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Gerrrt
Gerrrt force-pushed the gerrrt/network-md-hicks-reach branch from 840156e to 6ce11ed Compare September 4, 2026 13:30
Review of #272 caught a contradiction: the new footnote said Hicks is
"the only segment with a path into management" while the segment table
two rows above says the switch LAN reaches Everything. Reading for it
found a second exception the footnote also missed — ImaginationLAN
carries two host-scoped passes to 10.0.99.20, for Saruman's Alloy agent
and the iLO's return path. The pre-existing sentence at the head of the
Hicks section made the same "only" claim and is corrected with it.

Also from the review: security.md said Hicks reaching all of
ImaginationLAN is something "no rule grants and no rule denies". The
catch-all is itself a grant, and since 2026-09-02 there is also a rule
that names the segment. Say what is true — nothing denies it, and what
grants it is the catch-all rather than a decision about that segment.

And write both ingest ports as full host:port pairs in the two places
that abbreviated the second to ":3100".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Gerrrt
Gerrrt merged commit aad6d49 into main Sep 4, 2026
3 checks passed
@Gerrrt
Gerrrt deleted the gerrrt/network-md-hicks-reach branch September 4, 2026 13:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants