Session log: IMC SQL move + DISM repair attempt, VWP RDWeb brute-force incident, Dataforth API planning
- IMC: document 716 GB SQL backup cleanup, retention scheduled task, DB move C:->S:, sysadmin grant via single-user recovery, parked RDS removal after KB5075999 apply rolled back on ETW manifest error - Valleywide: document RDWeb brute-force incident on VWP-QBS, UDM port forward closure, 30-day audit showing no breach, lockout policy restoration - Dataforth: capture Swagger API review and Hoffman Zoom call prep
This commit is contained in:
52
clients/valleywide/README.md
Normal file
52
clients/valleywide/README.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Valleywide (VWP)
|
||||
|
||||
## Infrastructure
|
||||
|
||||
### Servers
|
||||
|
||||
**VWP_ADSRVR (192.168.0.25)**
|
||||
- Windows Server 2019 Standard (build 17763)
|
||||
- Domain Controller for `vwp.local`
|
||||
- SSH enabled (OpenSSH Server), key auth working for `vwp\guru`
|
||||
|
||||
**VWP-QBS (172.16.9.169)**
|
||||
- Windows Server 2022 Standard
|
||||
- Internal network only (172.16.9.0/24 reachable via VWP site VPN)
|
||||
- Runs QuickBooks + **IIS with RD Gateway / RD Web Access** (`/RDWeb`, `/RDWeb/Pages`, `/RDWeb/Feed`, `/Rpc`, `/RpcWithCert`)
|
||||
- WinRM available on 5985 (used for remote admin via Invoke-Command)
|
||||
|
||||
### Networks
|
||||
- Internal: `172.16.9.0/24`
|
||||
- One subnet also numbered `192.168.0.0/24` (conflicts with IMC's LAN if VPNs overlap — be careful switching contexts)
|
||||
|
||||
### Access
|
||||
- **SSH to VWP_ADSRVR:** `ssh vwp\guru@192.168.0.25` (ed25519 key, added 2026-04-13)
|
||||
- **Double-hop to VWP-QBS:** SSH won't forward Kerberos; use `Invoke-Command -ComputerName VWP-QBS -Credential $cred` with `vwp\sysadmin` PSCredential
|
||||
|
||||
## Security posture
|
||||
|
||||
### 2026-04-13 incident
|
||||
RDWeb (`https://VWP-QBS/RDWeb/Pages/login.aspx`) was exposed to the public internet via UDM port forward. Distributed brute-force attack was in progress (multiple external IPs, ~6 POSTs/min, hitting usernames like `scanner`, `Guest`, etc.). This was discovered while investigating repeated `scanner` account lockouts (event 4740) which originally looked like a stale service credential.
|
||||
|
||||
**Actions taken:**
|
||||
- UDM port forward removed (user action)
|
||||
- IIS reset on VWP-QBS to drain in-flight attacker sessions
|
||||
- Domain lockout policy restored (threshold 5, 16-min duration/window) after being temporarily disabled during diagnosis
|
||||
- 30-day audit: **no successful external logons** — no compromise
|
||||
|
||||
### Current state
|
||||
- RDWeb no longer reachable from public internet
|
||||
- Internal access still works on port 443 from within 172.16.9.0/24
|
||||
- Account lockout policy active
|
||||
|
||||
### Recommendations (outstanding)
|
||||
- If RDWeb must be public again: deploy **IPBan** (https://github.com/DigitalRuby/IPBan) + firewall restriction to known client IPs
|
||||
- Audit UDM for UPnP (prevents the server from re-punching its own hole)
|
||||
- Consider 2FA / Conditional Access on any externally-reachable Windows service
|
||||
- Rotate `scanner` AD account password (last set 2024-10-17) as hygiene
|
||||
|
||||
## Open items
|
||||
|
||||
- Confirm UPnP state on UDM
|
||||
- Document intended RDWeb access pattern (who connects from where)
|
||||
- Add Valleywide entry to SOPS vault
|
||||
Reference in New Issue
Block a user