DECNET/development/HARDENING.md

# OS Fingerprint Spoofing — Hardening Roadmap

This document describes the current state of OS fingerprint spoofing in DECNET
and the planned improvements to make `nmap -O`, `p0f`, and similar passive/active
scanners see the intended OS rather than a generic Linux kernel.

---

## Current State (Post-Phase 1)

Phase 1 is **implemented and tested against live scans**. Each archetype declares
an `nmap_os` slug (e.g. `"windows"`, `"linux"`, `"embedded"`). The **composer**
resolves that slug via `os_fingerprint.get_os_sysctls()` and injects the resulting
kernel parameters into the **base container** as Docker `sysctls`. Service
containers inherit the same network namespace via `network_mode: "service:<base>"`
and therefore appear identical to outside scanners.

### Implemented sysctls (8 per OS profile)

| Sysctl | Purpose | Win | Linux | Embedded |
|---|---|---|---|---|
| `net.ipv4.ip_default_ttl` | TTL discriminator | `128` | `64` | `255` |
| `net.ipv4.tcp_syn_retries` | SYN retransmit count | `2` | `6` | `3` |
| `net.ipv4.tcp_timestamps` | TCP timestamp option (OPS probes) | `0` | `1` | `0` |
| `net.ipv4.tcp_window_scaling` | Window scale option | `1` | `1` | `0` |
| `net.ipv4.tcp_sack` | Selective ACK option | `1` | `1` | `0` |
| `net.ipv4.tcp_ecn` | ECN negotiation | `0` | `2` | `0` |
| `net.ipv4.ip_no_pmtu_disc` | DF bit in ICMP replies | `0` | `0` | `1` |
| `net.ipv4.tcp_fin_timeout` | FIN_WAIT_2 timeout (seconds) | `30` | `60` | `15` |

### Live scan results (Windows decky, 2026-04-10)

**What works:**

| nmap field | Expected | Got | Status |
|---|---|---|---|
| TTL (`T=`) | `80` (128 dec) | `T=80` | ✅ |
| TCP timestamps (`TS=`) | `U` (unsupported) | `TS=U` | ✅ |
| ECN (`CC=`) | `N` | `CC=N` | ✅ |
| TCP window (`W1=`) | `FAF0` (64240) | `W1=FAF0` | ✅ |
| Window options (`O1=`) | `M5B4NNSNWA` | `O1=M5B4NNSNWA` | ✅ |
| SACK | present | present | ✅ |
| DF bit | `DF=Y` | `DF=Y` | ✅ |

**What fails:**

| nmap field | Expected (Win) | Got | Impact |
|---|---|---|---|
| IP ID (`TI=`) | `I` (incremental) | `Z` (all zeros) | **Critical** — no Windows fingerprint in nmap's DB has `TI=Z`. This alone causes 91% confidence "Linux 2.4/2.6 embedded" |
| ICMP rate limiting | unlimited | Linux default rate | Minor — affects `IE`/`U1` probe groups |

**Key finding:** `TI=Z` is the **single remaining blocker** for a convincing
Windows fingerprint. Everything else (TTL, window, timestamps, ECN, SACK, DF)
is already correct. The Phase 2 window mangling originally planned is
**unnecessary** — the kernel already produces the correct 64240 value.

---

## Remaining Improvement Phases

### Phase 2 — ICMP Tuning via Sysctls (Low effort, Medium impact)

Two additional namespace-scoped sysctls control ICMP error rate limiting.
nmap's `IE` and `U1` probe groups measure how quickly the target responds to
ICMP and UDP-to-closed-port probes.

**Changes required:** add to `OS_SYSCTLS` in `decnet/os_fingerprint.py`.

| Sysctl | What it controls | Windows | Linux | Embedded |
|---|---|---|---|---|
| `net.ipv4.icmp_ratelimit` | Minimum ms between ICMP error messages | `0` (none) | `1000` (1/sec) | `1000` |
| `net.ipv4.icmp_ratemask` | Bitmask of ICMP types subject to rate limiting | `0` | `6168` | `6168` |

**Why:** Windows does not rate-limit ICMP error responses. Linux defaults to
1000ms between ICMP errors (effectively 1 per second per destination). When
nmap sends rapid-fire UDP probes to closed ports, a Windows machine replies to
all of them instantly while a Linux machine throttles responses. Setting
`icmp_ratelimit=0` for Windows makes the `U1` probe response timing match.

**Estimated effort:** 15 min — same pattern as Phase 1, just two more entries.

---

### Phase 3 — NFQUEUE IP ID Rewriting (Medium effort, Very high impact)

This is the **highest-priority remaining item** and the only way to fix `TI=Z`.

#### Root cause of `TI=Z`

The Linux kernel's `ip_select_ident()` function sets the IP Identification
field to `0` for all TCP packets where DF=1 (don't-fragment bit set). This is
correct behavior per RFC 6864 ("IP ID is meaningless when DF=1") but no Windows
fingerprint in nmap's database has `TI=Z`. **No namespace-scoped sysctl can
change this** — it's hardcoded in the kernel's TCP stack.

Note: `ip_no_pmtu_disc` does NOT fix this. That sysctl controls Path MTU
Discovery for UDP/ICMP paths only, not TCP IP ID generation. Setting it to 1
for Windows was tested and confirmed to have no effect on `TI=Z`.

#### Solution: NFQUEUE userspace packet rewriting

Use `iptables -t mangle` to send outgoing TCP packets to an NFQUEUE, where a
small Python daemon rewrites the IP ID field before release.

```
                    ┌──────────────────────────┐
 TCP SYN-ACK  ───► │ iptables mangle/OUTPUT   │
                    │ -j NFQUEUE --queue-num 0 │
                    └───────────┬──────────────┘
                                ▼
                    ┌──────────────────────────┐
                    │  Python NFQUEUE daemon   │
                    │  1. Read IP ID field     │
                    │  2. Replace with target  │
                    │     pattern (sequential  │
                    │     for Windows, zero    │
                    │     for embedded, etc.)  │
                    │  3. Recalculate checksum │
                    │  4. Accept packet        │
                    └───────────┬──────────────┘
                                ▼
                         Packet goes out
```

**Target IP ID patterns by OS:**

| OS | nmap label | Pattern | Implementation |
|---|---|---|---|
| Windows | `TI=I` | Sequential, incrementing by 1 per packet | Global atomic counter |
| Linux 3.x+ | `TI=Z` | Zero (DF=1) or randomized | Leave untouched (already correct) |
| Embedded/Cisco | `TI=I` or `TI=Z` | Varies by device | Sequential or zero |
| BSD | `TI=RI` | Randomized incremental | Counter + small random delta |

**Two possible approaches:**

1. **TCPOPTSTRIP + NFQUEUE (comprehensive)**
   - `TCPOPTSTRIP` can strip/modify TCP options (window scale, SACK, etc.)
     via pure iptables rules, no userspace needed
   - `NFQUEUE` handles IP-layer rewriting (IP ID) in userspace
   - Combined: full control over the TCP/IP fingerprint

2. **NFQUEUE only (simpler)**
   - Single Python daemon handles everything: IP ID rewriting, and optionally
     TCP option/window manipulation if ever needed
   - Fewer moving parts, one daemon to monitor

**Required changes:**
- `templates/base/Dockerfile` — new, installs `iptables` + `python3-netfilterqueue`
- `templates/base/entrypoint.sh` — new, sets up iptables rules + launches daemon
- `templates/base/nfq_spoofer.py` — new, the NFQUEUE packet rewriting daemon
- `os_fingerprint.py` — add `ip_id_pattern` field to each OS profile
- `composer.py` — pass `SPOOF_IP_ID` env var + use `templates/base/Dockerfile`
  instead of bare distro images for base containers

**Dependencies on the host kernel:**
- `nfnetlink_queue` module (`modprobe nfnetlink_queue`)
- `xt_NFQUEUE` module (standard in all distro kernels)
- `NET_ADMIN` capability (already granted)

**Dependencies in the base container image:**
- `iptables` package
- `python3` + `python3-netfilterqueue` (or `scapy` with `NetfilterQueue`)

**Estimated effort:** 4–6 hours + tests

---

### Phase 4 — Full Fingerprint Database Matching (Hard, Low marginal impact)

After Phases 2–3, the remaining fingerprint differences are increasingly minor:

| Signal | Current | Notes |
|---|---|---|
| TCP initial sequence number (ISN) pattern (`SP=`, `ISR=`) | Linux kernel default | Kernel-level, not spoofable without userspace TCP |
| TCP window variance across probes | Constant (`FAF0` × 6) | Real Windows sometimes varies slightly |
| T2/T3 responses | `R=N` (no response) | Correct for some Windows, wrong for others |
| ICMP data payload echo | Linux default | Difficult to control per-namespace |

These are diminishing returns. With Phases 1–3 complete, `nmap -O` should
correctly identify the OS family in >90% of scans.

> Phase 4 is **not recommended** for the near term. Effort is measured in days
> for single-digit percentage improvements.

---

## Implementation Priority (revised)

```
Phase 1  ✅ DONE ─────────────────────────────
  └─ 8 sysctls per OS in os_fingerprint.py
  └─ Verified: TTL, window, timestamps, ECN, SACK all correct

Phase 2  ──────────────────────────────── (implement next)
  └─ 2 more sysctls: icmp_ratelimit + icmp_ratemask
  └─ Estimated effort: 15 min

Phase 3  ──────────────────────────────── (high priority)
  └─ NFQUEUE daemon in templates/base/
  └─ Fix TI=Z for Windows (THE remaining blocker)
  └─ Estimated effort: 4–6 hours + tests

Phase 4  ──────────────────────────────── (not recommended)
  └─ ISN pattern, T2/T3, ICMP payload echo
  └─ Estimated effort: days, diminishing returns
```

---

## Testing Strategy

After each phase, validate with:

```bash
# Active OS fingerprint scan against a deployed decky
sudo nmap -O --osscan-guess <decky_ip>

# Aggressive scan with version detection
sudo nmap -sV -O -A --osscan-guess <decky_ip>

# Passive fingerprinting (run on host while generating traffic to decky)
sudo p0f -i <macvlan_interface> -p

# Quick TTL + window check
hping3 -S -p 445 <decky_ip>   # inspect TTL and window in reply

# Test INI (all OS families, 10 deckies)
sudo .venv/bin/decnet deploy --config arche-test.ini --interface eth0
```

### Expected outcomes by phase

| Check | Pre-Phase 1 | Post-Phase 1 ✅ | Post-Phase 2 | Post-Phase 3 |
|---|---|---|---|---|
| TTL | ✅ | ✅ | ✅ | ✅ |
| TCP timestamps | ❌ | ✅ | ✅ | ✅ |
| TCP window size | ❌ | ✅ (kernel default OK) | ✅ | ✅ |
| ECN | ❌ | ✅ | ✅ | ✅ |
| ICMP rate limiting | ❌ | ❌ | ✅ | ✅ |
| IP ID sequence (`TI=`) | ❌ | ❌ | ❌ | ✅ |
| `nmap -O` family match | ⚠️ | ⚠️ (TI=Z blocks) | ⚠️ | ✅ |
| `p0f` match | ⚠️ | ⚠️ | ✅ | ✅ |

### Note on `P=` field in nmap output

The `P=x86_64-redhat-linux-gnu` that appears in the `SCAN(...)` block is the
**GNU build triple of the nmap binary itself**, not a fingerprint of the target.
It cannot be changed and is not relevant to OS spoofing.