sync: auto-sync from HOWARD-HOME at 2026-06-01 13:46:39

Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-01 13:46:39
2026-06-01 13:46:54 -07:00
parent 589c32c52e
commit 8e14422a5f
3 changed files with 304 additions and 4 deletions
--- a/clients/dataforth/docs/aoi-xp-vlan-backup-runbook.md
+++ b/clients/dataforth/docs/aoi-xp-vlan-backup-runbook.md
@@ -0,0 +1,184 @@
+# Dataforth — AOI / XP Optical-Tester VLAN + Backup Runbook
+
+**Todo:** `37543f7f` · **Requested by:** Mike (relayed via Howard) · **Started:** 2026-06-01
+**Goal:** Isolate the XP machine (which holds the AOI optical-inspection data) on its own VLAN,
+and give it — and only it — access to a new backup share on D2TESTNAS over SMB1.
+
+---
+
+## >>> ACTUAL OUTCOME (2026-06-01) — this overrides the planned specifics below <<<
+
+The plan below was drafted around a hypothetical new "VLAN 50". **What was actually done:**
+
+- **VLAN:** XP placed on the **existing VLAN 2 "mydata"** (the SMT line, `192.168.1.0/24`), not a new
+  VLAN. Moved **D2-Breakroom switch port 12** to mydata. XP static IP **192.168.1.175**, gw/DNS 192.168.1.1.
+- **Share:** `\\192.168.0.9\aoibackup` on D2TESTNAS — `valid users = admin` (password matches XP login),
+  `hosts allow = 192.168.1.175`, `browseable = no`. **DEPLOYED + verified** (XP maps Z: r/w).
+- **NAS hardening:** `test`/`datasheets`/`snapshots` shares now `hosts deny = 192.168.1.175`; rsync(873)
+  already excludes the XP. The XP can touch ONLY `aoibackup` on the NAS.
+- **Credentials in vault:** `clients/dataforth/d2testnas.sops.yaml → credentials.smb.aoi-user`(=`admin`)
+  /`.aoi-password`/`.aoi-share`.
+- **Firewall (UDM):** Per **Mike** — *"it's part of SMT, so it can see anything in SMT"* — NO intra-SMT
+  restriction. **Optional pending:** block XP(.175) → company LAN 192.168.0.0/24 (except NAS) + Internet.
+- D2TESTNAS confirmed **Debian 13 / Samba 4.22.6** (repurposed Netgear ReadyNAS).
+
+Read the section below as background/reference only; the specifics above are the source of truth.
+
+---
+
+## The setup (as understood)
+
+- **AOI machine** = Automated Optical Inspection unit. Photographs circuit boards for production
+  defects. Not a PC — it writes image data to an **external drive attached to an XP machine**.
+- **XP machine** = the actual target. Holds the AOI external drive. Windows XP → cannot do SMB2/3,
+  must use **SMB1**.
+- **Backup target** = a new, locked-down share on **D2TESTNAS** (192.168.0.9). Only the XP may reach it.
+
+## Why D2TESTNAS (not a server)
+
+D2TESTNAS already runs **SMB1 globally** for the 64 DOS 6.22 test stations
+(`server min protocol = CORE`, `ntlm auth = ntlmv1-permitted`). Pointing the XP box at it adds
+**zero new SMB1 surface**. Enabling SMB1 on AD1/AD2 (Server 2016/2022) would create fresh
+EternalBlue-class exposure on a domain controller — rejected. Security note in the todo:
+"minimize SMB1 exposure — scope it to just the required server/share."
+
+## Verified remotely (2026-06-01, before onsite)
+
+| Item | Finding |
+|---|---|
+| D2TESTNAS OS | **Debian 13 (trixie)**, kernel 6.12, Samba **4.22.6**. (Wiki said CachyOS, vault said Netgear ReadyNAS — both stale. Was a Netgear, repurposed. Corrected.) |
+| SMB1 | Already enabled globally (CORE..SMB3, NTLMv1 permitted, WINS on, workgroup `D2TESTING`). |
+| Existing shares | `test`, `datasheets`, `snapshots` — all **guest/public, wide open**. New AOI share will be the opposite: authenticated + host-locked. |
+| SMB accounts | **None** (DOS shares are guest). Will create a dedicated `aoi` user. |
+| Disk | `/data` = 512 G, **71 G free (87 % full)**. ⚠ Confirm AOI data size + retention before bulk copy. |
+| NAS host firewall | None restrictive (only Tailscale nft). Isolation enforced at **UDM**, Samba `hosts allow` = defense-in-depth. |
+| UDM SSH | Password auth rejected (publickey + keyboard-interactive only; 2FA push on). `id_ed25519_udm` key not on Howard-Home → **UDM work is onsite via UniFi UI**, or add this machine's key first. |
+
+---
+
+## ONSITE — collect these first
+
+1. **XP hostname**, current IP, and **MAC address** (`ipconfig /all` on the XP).
+2. **Which switch + port** the XP is patched into (for the VLAN port profile).
+3. **XP login username** (local or domain? has a password?) — needed for the scheduled-task run-as.
+4. **AOI external drive letter + data path** (e.g. `E:\AOI_Data\...`), rough **size** and **growth rate**.
+5. **Existing VLANs** — UniFi → Settings → Networks. Confirm proposed **VLAN 50 / 192.168.50.0/24**
+   is free (known in use: default 192.168.0.0/24, Voice VLAN 100 = 192.168.100.0/24,
+   unused UDM voice 192.168.1.0/24, OpenVPN 192.168.6.0/24).
+
+---
+
+## Step 1 — UDM: create the isolation VLAN (UniFi UI)
+
+Settings → Networks → **New Virtual Network**:
+- Name: `AOI-Isolated`
+- VLAN ID: **50** (or next free)
+- Gateway/Subnet: `192.168.50.1/24`
+- DHCP: enable, but give the XP a **fixed IP** — either DHCP reservation by MAC or set the XP static
+  to **192.168.50.10** (fixed IP keeps the firewall rule simple). Proposed: **192.168.50.10**.
+- DNS: not required for backup-by-IP. Leave gateway default.
+- **Do NOT use the simple "Isolate Network" toggle** — it's all-or-nothing and would also block the
+  one flow we need. Use explicit firewall rules (Step 3) instead.
+
+## Step 2 — UDM: assign the XP's switch port to VLAN 50
+
+UniFi → switch → the XP's port → set **Native/Access VLAN = AOI-Isolated (50)**, tagged VLANs none.
+(Effectively an access port on VLAN 50.) Confirm the AOI machine itself does NOT share this port/run
+through the XP's NIC — if the AOI unit is daisy-chained behind the XP, flag it before changing the port.
+
+## Step 3 — UDM: firewall rules (order matters — allow before block)
+
+Zone-based firewall (new UniFi OS) or LAN IN (classic). Source = `AOI-Isolated (VLAN 50)`:
+
+1. **ALLOW** → dest host `192.168.0.9` → **TCP 445, TCP 139** → Accept
+   *(XP maps by IP; Windows tries 445 then 139. Add UDP 137 only if name resolution is needed.)*
+2. **DROP** → dest `192.168.0.0/24` (rest of LAN) → Drop
+3. **DROP** → dest `192.168.100.0/24` (voice) and any other internal VLANs → Drop
+4. **DROP** → Internet/WAN (an XP box should not reach the internet) → Drop
+   *(If the AOI/XP needs NTP or a license server, add a narrow allow above this.)*
+- Return traffic (established/related) is handled automatically by UniFi.
+
+## Step 4 — D2TESTNAS: create the locked-down share
+
+Run remotely (Claude can apply once XP IP is known) or onsite via SSH `root@192.168.0.9`.
+Substitute the XP's VLAN IP for `192.168.50.10`:
+
+```bash
+# 1. backup dir
+mkdir -p /data/aoi-backup
+chown root:root /data/aoi-backup
+chmod 0770 /data/aoi-backup
+
+# 2. dedicated samba user (NOT a Linux login shell)
+useradd -M -s /usr/sbin/nologin aoi 2>/dev/null || true
+smbpasswd -a aoi        # set a strong password -> store in vault clients/dataforth/d2testnas.sops.yaml
+smbpasswd -e aoi
+
+# 3. append share stanza to /etc/samba/smb.conf
+cat >> /etc/samba/smb.conf <<'EOF'
+
+[aoibackup]
+    path = /data/aoi-backup
+    comment = AOI Optical Tester Backup (XP only)
+    browseable = no
+    writable = yes
+    guest ok = no
+    public = no
+    valid users = aoi
+    force user = root
+    force group = root
+    create mask = 0660
+    directory mask = 0770
+    hosts allow = 192.168.50.10
+    hosts deny = 0.0.0.0/0
+EOF
+
+# 4. validate + reload
+testparm -s
+systemctl reload smbd
+```
+
+Notes:
+- `browseable = no` hides the share; `valid users = aoi` + `hosts allow` = two independent gates.
+- Global `ntlm auth = ntlmv1-permitted` already lets XP authenticate over SMB1 — no global change.
+- Store the `aoi` password in vault: `clients/dataforth/d2testnas.sops.yaml → credentials.smb.aoi`.
+
+## Step 5 — XP: map the drive + scheduled backup
+
+XP has no robocopy. Use `net use` + `xcopy` (incremental via `/D`). On the XP:
+
+```bat
+net use Z: \\192.168.0.9\aoibackup <aoi-password> /user:aoi /persistent:yes
+xcopy "E:\AOI_Data\*" "Z:\" /D /E /C /I /H /R /Y
+```
+*(Replace `E:\AOI_Data` with the real AOI external-drive path. `/D` copies only newer files = incremental.)*
+
+Schedule it (XP Task Scheduler or `schtasks`), e.g. daily off-shift:
+```bat
+schtasks /Create /TN "AOI Backup" /TR "C:\Scripts\aoi-backup.bat" /SC DAILY /ST 23:00 /RU <xp-user>
+```
+Put the two commands above in `C:\Scripts\aoi-backup.bat`.
+
+## Step 6 — Verify
+
+- From the XP: `net use` shows Z: connected; create a test file on Z:, confirm it lands in
+  `/data/aoi-backup` on the NAS.
+- From a **different** LAN host: confirm `\\192.168.0.9\aoibackup` is **denied** (host-locked).
+- Confirm the XP **cannot** ping/reach other LAN hosts (e.g. `ping 192.168.0.27` fails) and has no internet.
+- Run the scheduled task once manually; confirm files copy.
+
+## Step 7 — Document
+
+- Update `wiki/clients/dataforth.md`: add XP/AOI to workstation inventory, new VLAN 50 row, the
+  `aoibackup` share, firewall ACL, and correct D2TESTNAS OS (Debian 13). Add Active Work + History entries.
+- Correct the vault `os:` field on `clients/dataforth/d2testnas.sops.yaml` (Netgear ReadyNAS → Debian 13).
+- Close todo `37543f7f`; update coord component `clients/dataforth`.
+
+---
+
+## Open questions for Mike / to resolve onsite
+
+- AOI data **size + growth** vs. 71 G free — full mirror or incremental+retention? Prune policy?
+- Is the **AOI unit networked separately**, or only ever via the XP's external drive? (Affects whether
+  anything else needs VLAN 50 access.)
+- Does the XP need **any** other LAN/internet flow to function (license, time, AOI vendor)? Default: none.
--- a/clients/dataforth/session-logs/2026-06-01-aoi-xp-vlan-share.md
+++ b/clients/dataforth/session-logs/2026-06-01-aoi-xp-vlan-share.md
@@ -0,0 +1,108 @@
+# Dataforth — AOI / XP Optical-Tester VLAN + SMB1 Backup Share
+
+**Date:** 2026-06-01
+**Todo:** `37543f7f` (still OPEN — network isolation incomplete)
+**Mode:** infra
+
+## User
+- **User:** Howard Enos (howard)
+- **Machine:** Howard-Home
+- **Role:** tech
+
+---
+
+## Objective
+
+Mike's request (relayed via Howard): the **AOI** machine (Automated Optical Inspection — photographs
+circuit boards for SMT production defects) dumps data to an **external drive on a Windows XP PC**.
+Isolate that XP PC on a VLAN and give it — and only it — a backup share on **D2TESTNAS**. XP is
+SMB1-only, so the target must speak SMB1; do **not** enable SMB1 on any modern server (security).
+
+## What got done
+
+### Backup share on D2TESTNAS (192.168.0.9) — COMPLETE
+- D2TESTNAS verified to be **Debian 13 (trixie), Samba 4.22.6** (it was a Netgear ReadyNAS, since
+  repurposed; wiki said CachyOS and vault said Netgear — both were stale, both corrected).
+- SMB1 already enabled **globally** for the 64 DOS 6.22 stations (`server min protocol = CORE`,
+  `ntlm auth = ntlmv1-permitted`), so the XP needed **no new SMB1 surface** — just a new share.
+- Created `/data/aoi-backup` + share `[aoibackup]`:
+  - `valid users = admin`, `hosts allow = 192.168.1.175`, `hosts deny = 0.0.0.0/0`, `browseable = no`,
+    `force user = root`, writable.
+  - Samba account `admin` / password matches the XP's local login (set by Howard, per user request).
+  - Credentials stored in vault: `clients/dataforth/d2testnas.sops.yaml → credentials.smb.aoi-user`
+    (= `admin`) and `.aoi-password`. (Password is weak — acceptable only because the share is
+    IP-locked + the account is shell-less and NAS-only. Revisit if the box ever leaves the segment.)
+- **Verified:** XP mapped `Z: \\192.168.0.9\aoibackup` successfully (read/write works).
+
+### Lateral-movement hardening on the NAS — COMPLETE
+- The NAS's other shares (`test`, `datasheets`, `snapshots`) are wide-open **guest, writable**.
+  The XP can reach the NAS, so it could also have written into the DOS `test` share → potential
+  virus jump to the 64 DOS stations.
+- Added `hosts deny = 192.168.1.175` to `test`, `datasheets`, `snapshots`. Blocks **only** the XP;
+  DOS stations (192.168.0.x) unaffected. rsync daemon (873) already excludes the XP
+  (`hosts allow = 192.168.0.0/24 172.16.0.0/12`).
+- Net effect on the NAS: the XP can touch **only** `aoibackup`, and **only** the XP can write
+  `aoibackup`. Containment is bidirectional at the NAS layer.
+
+### VLAN — PARTIAL
+- Decision changed mid-session: instead of a new isolated VLAN 50, the XP was placed on the
+  **existing VLAN 2 "mydata"** (`192.168.1.0/24`). Howard moved **D2-Breakroom switch port 12** to
+  mydata and rebooted; XP now at **192.168.1.175** (static, DNS = gateway 192.168.1.1).
+
+## Network isolation — Mike's decision (2026-06-01)
+
+Howard asked Mike about adding firewall rules. **Mike:** *"It's part of SMT, so it can see anything
+in SMT as far as I'm concerned."* → The AOI PC is a full SMT-VLAN citizen; **do NOT restrict it within
+mydata/SMT.** This also removes the risk of breaking the other SMT devices with VLAN-wide rules.
+
+Observed before the decision: from the XP, `ping 192.168.0.27` (AD1) **succeeded** → mydata has open
+inter-VLAN routing to the main LAN. Mike's call covers SMT-internal exposure but does **not** explicitly
+bless the XP reaching the **company core** (192.168.0.0/24 servers) or the **internet**.
+
+**Recommended (optional) hardening — scoped to the XP only, does NOT touch any other SMT device:**
+1. ALLOW `192.168.1.175` → `192.168.0.9` TCP 445,139 (the backup path)
+2. BLOCK `192.168.1.175` → `192.168.0.0/24` (company servers/workstations) — keeps an EOL XP off the
+   domain controllers while leaving all of SMT open per Mike
+3. BLOCK `192.168.1.175` → Internet/WAN (EOL box shouldn't browse)
+(DNS still works — pointed at gateway 192.168.1.1, intra-VLAN.) These are leave-or-take; if Mike wants
+zero restrictions, skip them. They will NOT affect goldstar19 / DESKTOP-FT0T4MK / My9-PC / the SMT
+machines, since they target only 192.168.1.175.
+
+## Why scope to the XP, not the VLAN — mydata is the live SMT line
+
+VLAN 2 "mydata" is the **SMT production network**, not a spare. Active devices:
+
+| Switch / Port | Device | MAC | Role |
+|---|---|---|---|
+| D2-Breakroom 12 | WinXPBE-724667 | …0f:17 | AOI PC (XP) 192.168.1.175 |
+| D2-SMT 1 | (unnamed) | 00:90:fb:80:f0:c6 | SMT equipment (industrial) |
+| D2-SMT 2 | goldstar19 | …68:9a | PC |
+| D2-SMT 3 | (unnamed) | 00:80:79:05:23:f2 | SMT equipment |
+| D2-SMT 5 | DESKTOP-FT0T4MK | …b6:ee | Windows desktop (GbE) |
+| D2-SMT 7 | (unnamed) | 00:80:79:04:47:e7 | SMT equipment |
+| D2-SMT 8 | My9-PC | …75:e0 | PC |
+| D2-SMT 4 / SFP+1 / SFP+2 | — | — | empty |
+
+A blanket mydata→LAN block could break the SMT PCs' access to servers (Sage, file shares) and the SMT
+machines' data flows. Hence: scope firewall rules to `192.168.1.175` only, and discuss broader SMT
+segmentation with Mike before touching VLAN-wide policy.
+
+## Vault changes
+- `clients/dataforth/d2testnas.sops.yaml`:
+  - `os` corrected → "Debian 13 (trixie), Samba 4.22.6 — repurposed from Netgear ReadyNAS"
+  - added `credentials.smb.aoi-user` = `admin`, `credentials.smb.aoi-password`, `credentials.smb.aoi-share`
+
+## Open / Next
+1. **DONE — Mike consulted.** Decision: XP stays open within SMT (no intra-SMT firewall rules).
+2. **Optional, Howard/Mike to decide:** apply the 2 protective rules that don't affect SMT —
+   block `192.168.1.175` → `192.168.0.0/24` (except the NAS) and → Internet. If approved, add on UDM,
+   then verify `ping 192.168.0.27` FAILs while `net use Z: \\192.168.0.9\aoibackup` still WORKs.
+3. Confirm the share deny worked: `net use Q: \\192.168.0.9\test` should be DENIED (the earlier test
+   used T:, which was already mapped — inconclusive).
+4. Samba verbose auth logging lowered back to `log level = 1` on D2TESTNAS (done this session).
+5. Todo `37543f7f`: core ask (VLAN placement + locked XP-only SMB1 share) COMPLETE. Left open only
+   pending the optional company-LAN/internet hardening decision; close once decided.
+
+## Reference
+- Runbook: `clients/dataforth/docs/aoi-xp-vlan-backup-runbook.md`
+- D2TESTNAS smb.conf backups: `/etc/samba/smb.conf.bak.*` (timestamped, per change)