block-nuke-telemetry/Advanced-Blocking-Methods.md

# Advanced Nuke Telemetry Blocking Methods

This document provides comprehensive guidance on blocking telemetry from The Foundry's Nuke compositor beyond basic hosts file blocking. All methods are designed for your specific installation at `/home/nicholai/Nuke15.2v6/`.

## Quick Reference

| Method | Effectiveness | Complexity | Nuke Functionality Impact |
|--------|---------------|------------|---------------------------|
| Hosts file blocking | Medium | Low | Minimal - Help menu may fail |
| Firewall (iptables/nftables) | **High** | Medium | Minimal - blocks by IP |
| Network namespace isolation | **Highest** | Medium | None - localhost preserved |
| AppArmor MAC | High | High | None - policy enforced at kernel |
| DNS sinkhole | Medium | Low | Minimal - depends on DNS setup |
| Automated monitoring | N/A (detection only) | Low | None - passive monitoring |

## Known Telemetry Endpoints

Based on packet capture analysis (see `nuke_foundry_analysis.md`):

| Domain | IP Address | Port | Protocol | Purpose |
|--------|-----------|------|----------|---------|
| `learn.foundry.com` | 52.50.232.31 | 80 | HTTP | Documentation checks (unencrypted) |
| `api.honeycomb.io` | 52.205.16.9 | 443 | HTTPS | Analytics/telemetry |
| `sentry.foundry.com` | (varies) | 443 | HTTPS | Crash reporting |

## Method 1: Firewall Blocking (Recommended)

**Why use this:** Blocks connections even if DNS resolves correctly; most robust defense against IP-based connections.

**Script:** `scripts/firewall_block_nuke.sh`

### Features:
- Blocks known Foundry telemetry IPs at the kernel level
- Supports both iptables (legacy) and nftables (modern)
- Persistent across reboots
- Includes restore/unblock functionality
- Logs blocked connection attempts

### Usage:
```bash
# Apply firewall blocks
cd /home/nicholai/Documents/obsidian-vault/2-projects/Nuke-monitoring
bash scripts/firewall_block_nuke.sh

# To unblock (run with --restore flag)
bash scripts/firewall_block_nuke.sh --restore

# Check current rules
sudo iptables -L OUTPUT -v -n | grep "52\\.50\\.232\\.31\\|52\\.205\\.16\\.9"
# Or for nftables:
sudo nft list ruleset | grep "52\\.50\\.232\\.31\\|52\\.205\\.16\\.9"
```

### How it works:
- Uses `iptables` or `nftables` OUTPUT chain to intercept outbound connections
- Rejects packets destined for Foundry IPs with ICMP host-unreachable
- Persists rules to `/etc/iptables/iptables.rules` or `/etc/nftables.conf`
- Can be combined with hosts file blocking for defense-in-depth

### Limitations:
- Requires root/sudo access
- If Foundry adds new IP addresses, rules must be updated
- May need adjustment if using Docker/virtual machines (bridge networks)

---

## Method 2: Network Namespace Isolation (Nuclear Option)

**Why use this:** Complete network isolation while preserving Nuke's localhost frameserver functionality.

**Script:** `scripts/nuke_isolated.sh`

### Features:
- Creates isolated network namespace with only loopback interface
- Blocks ALL external network access (not just Foundry)
- Frameserver communication still works (uses 127.0.0.1)
- Clean namespace cleanup on exit

### Usage:
```bash
# Launch Nuke in isolated namespace
bash scripts/nuke_isolated.sh

# Nuke will run with zero external network access
# Frameserver rendering still works normally
```

### How it works:
- Creates a Linux network namespace (`ip netns add nuke_isolated`)
- Enables only the loopback interface (lo)
- Launches Nuke inside the namespace with your user permissions
- Nuke cannot reach ANY external IPs, including telemetry servers

### Limitations:
- Breaks ALL network features (online help, license checks if using floating licenses, etc.)
- Requires sudo for namespace creation
- Slightly more complex troubleshooting if Nuke misbehaves

### When to use:
- Maximum privacy requirements
- Offline/air-gapped rendering workflows
- When you never use Nuke's online features

---

## Method 3: AppArmor Mandatory Access Control

**Why use this:** Kernel-enforced security policy; cannot be bypassed by the application.

**Profile:** `apparmor/nuke.profile`

### Features:
- Kernel-level enforcement (stronger than user-space blocking)
- Allows localhost, denies external network
- Granular file system access controls
- Audit mode for debugging

### Installation:
```bash
# Install the profile
sudo cp apparmor/nuke.profile /etc/apparmor.d/home.nicholai.Nuke15.2v6.Nuke15.2

# Load and enforce
sudo apparmor_parser -r /etc/apparmor.d/home.nicholai.Nuke15.2v6.Nuke15.2
sudo aa-enforce /home/nicholai/Nuke15.2v6/Nuke15.2

# Check status
sudo aa-status | grep Nuke

# Set to complain mode for testing (logs violations without blocking)
sudo aa-complain /home/nicholai/Nuke15.2v6/Nuke15.2

# Disable profile
sudo aa-disable /home/nicholai/Nuke15.2v6/Nuke15.2
```

### How it works:
- AppArmor kernel module intercepts Nuke's system calls
- Profile defines allowed operations (file access, network connections)
- Network rules: `deny network inet to !127.0.0.0/8` blocks non-localhost connections
- Violations are logged to `/var/log/audit/audit.log` or kernel log

### Limitations:
- Requires AppArmor-enabled kernel (default on Ubuntu, optional on Arch)
- Profile must be updated if Nuke changes installation paths
- Learning mode requires running Nuke extensively to capture all legitimate operations
- May need adjustments for render farm setups

### Troubleshooting:
```bash
# Check AppArmor is enabled
sudo systemctl status apparmor

# View denial logs
sudo journalctl -xe | grep apparmor | grep Nuke

# Generate profile from logs (if using complain mode)
sudo aa-logprof
```

---

## Method 4: DNS Sinkhole

**Why use this:** Centralized blocking across multiple machines; works network-wide if using Pi-hole or similar.

**Script:** `scripts/dns_sinkhole_config.sh`

### Features:
- Generates DNS configuration for various DNS servers
- Network-wide blocking if using Pi-hole/AdGuard Home
- Works for all devices querying your DNS server (75.75.75.75)

### Usage:
```bash
# Generate configs for your DNS setup
bash scripts/dns_sinkhole_config.sh

# Output includes snippets for:
# - dnsmasq
# - Pi-hole
# - AdGuard Home
# - BIND9

# Apply to your DNS server at 75.75.75.75
```

### How it works:
- DNS server returns 0.0.0.0 or 127.0.0.1 for Foundry domains
- Applications fail to connect before network traffic is sent
- Complements hosts file blocking (defense-in-depth)

### Your DNS Setup:
Based on your network configuration (DNS: 75.75.75.75), you're likely running:
- Pi-hole, AdGuard Home, dnsmasq, or custom DNS server

The script provides config snippets for all common platforms.

### Limitations:
- Requires access to DNS server configuration
- Doesn't block hardcoded IP addresses (combine with firewall rules)
- DNS cache may delay blocking (flush with `sudo systemd-resolve --flush-caches`)

---

## Method 5: Automated Monitoring and Alerts

**Why use this:** Detect new telemetry endpoints or verify blocking effectiveness.

**Script:** `scripts/monitor_nuke_network.sh`

### Features:
- Monitors Nuke processes for external network connections
- Desktop notifications (via `notify-send`)
- Logs alerts to `nuke_telemetry_alerts.log`
- Can run continuously or via cron/systemd timer

### Usage:
```bash
# Run monitoring in background
bash scripts/monitor_nuke_network.sh &

# Or set up as cron job (check every 5 minutes)
crontab -e
# Add: */5 * * * * /home/nicholai/Documents/obsidian-vault/2-projects/Nuke-monitoring/scripts/monitor_nuke_network.sh

# Or as systemd timer (advanced - see script comments)

# View alerts log
tail -f nuke_telemetry_alerts.log
```

### How it works:
- Uses `pgrep` to find Nuke processes
- Queries socket connections with `ss -tnp`
- Filters out localhost (127.0.0.1) connections
- Alerts when external connections detected
- Useful for discovering new telemetry endpoints Foundry may add

### Example alert:
```
[2025-11-25 14:23:15] ALERT: Nuke external connection detected
Process: Nuke15.2 (PID 867114)
Connection: 10.0.0.50:54321 -> 52.205.16.9:443 (ESTABLISHED)
Domain: api.honeycomb.io
```

### Limitations:
- Passive monitoring only (doesn't block)
- Requires Nuke to be running during checks
- Desktop notifications need X11/Wayland session

---

## Recommended Approach

For maximum effectiveness, use **layered defense**:

### Tier 1: Essential (Apply First)
1. **Hosts file blocking** (already applied via `block_nuke_telemetry.sh`)
2. **Firewall rules** (`scripts/firewall_block_nuke.sh`)
   - Blocks even if DNS resolves
   - Most important addition

### Tier 2: Enhanced Privacy
3. **Automated monitoring** (`scripts/monitor_nuke_network.sh`)
   - Catches new endpoints Foundry may add
   - Validates blocking effectiveness

### Tier 3: Maximum Isolation (Optional)
4. **Network namespace** (`scripts/nuke_isolated.sh`)
   - Use when you need absolute certainty
   - Acceptable if you never use online features

5. **AppArmor profile** (`apparmor/nuke.profile`)
   - Kernel-enforced policy
   - Good for multi-user systems or render farms

### Tier 4: Network-Wide (Optional)
6. **DNS sinkhole** (`scripts/dns_sinkhole_config.sh`)
   - If you run Pi-hole or custom DNS
   - Protects other machines on your network

## Verification Commands

After applying blocking methods, verify effectiveness:

### Test DNS resolution:
```bash
# Should resolve to 127.0.0.1 or fail
nslookup api.honeycomb.io
nslookup learn.foundry.com
nslookup sentry.foundry.com
```

### Test network connectivity:
```bash
# Should timeout or show connection refused
curl -I http://learn.foundry.com --max-time 5
curl -I https://api.honeycomb.io --max-time 5
curl -I https://sentry.foundry.com --max-time 5
```

### Capture Nuke traffic:
```bash
# Run Nuke, then check for external connections
sudo tcpdump -i any -n 'host 52.50.232.31 or host 52.205.16.9' -c 10

# Should see zero packets if blocking is effective
```

### Check firewall rules:
```bash
# iptables
sudo iptables -L OUTPUT -v -n | grep -E "52\.50\.232\.31|52\.205\.16\.9"

# nftables
sudo nft list ruleset | grep -E "52\.50\.232\.31|52\.205\.16\.9"
```

### Monitor active connections:
```bash
# While Nuke is running
sudo ss -tnp | grep Nuke | grep -v 127.0.0.1

# Should only show localhost connections (frameserver)
```

## Troubleshooting

### Nuke won't launch after applying blocks
1. Check AppArmor isn't blocking file access:
   ```bash
   sudo aa-complain /home/nicholai/Nuke15.2v6/Nuke15.2
   ```
2. Verify network namespace script uses correct executable path
3. Check firewall rules aren't blocking localhost (should never happen with provided scripts)

### Help menu doesn't work
**Expected behavior** - Help menu requires `learn.foundry.com` access. This is blocked intentionally.

Workaround: Use offline documentation or temporarily disable blocks:
```bash
# Disable firewall temporarily
sudo iptables -D OUTPUT -d 52.50.232.31 -j REJECT

# Re-enable after using help
sudo iptables -A OUTPUT -d 52.50.232.31 -j REJECT --reject-with icmp-host-unreachable
```

### Frameserver rendering fails
Network namespace isolation should NOT affect frameserver (uses localhost).

If rendering fails:
1. Check you're not blocking localhost in firewall rules
2. Verify loopback interface is up: `ip addr show lo`
3. Test localhost: `ping -c 1 127.0.0.1`

### New telemetry endpoint discovered
Update firewall and hosts files:

```bash
# Find new IP
sudo tcpdump -i any -n 'not net 10.0.0.0/8 and not net 127.0.0.0/8' | grep -i foundry

# Add to firewall
sudo iptables -A OUTPUT -d <new_ip> -j REJECT --reject-with icmp-host-unreachable
sudo iptables-save | sudo tee /etc/iptables/iptables.rules

# Add to hosts file
echo "127.0.0.1 <new_domain>" | sudo tee -a /etc/hosts
```

### Monitoring script shows false positives
Frameserver connections to 127.0.0.1 are expected.

Filter these out - the provided script already excludes localhost.

If you see connections to your local network (10.0.0.0/8), these may be:
- Render farm nodes
- Shared storage (NAS/NFS)
- License servers (floating licenses)

Not telemetry - these are normal.

## Privacy Assessment

**With all methods applied:**
- Telemetry transmission: **Blocked** ✓
- Crash reporting: **Blocked** ✓
- Documentation checks: **Blocked** ✓
- ISP/network visibility: **Eliminated** (no packets leave your machine)
- Foundry data collection: **Prevented** ✓

**Remaining exposure:**
- Local Nuke files still created (`~/.nuke/`, `~/Documents/nuke/`)
- Crash dumps cached locally in `sentry-db/` (not transmitted)
- License file may contain machine ID (needed for licensing)

**Verification:** Run monitoring script for 24 hours to confirm zero external connections.

## Performance Impact

All blocking methods have **negligible performance impact**:
- Hosts file: ~microseconds per DNS lookup
- Firewall: ~nanoseconds per packet (kernel-space)
- Network namespace: ~milliseconds at launch (one-time)
- AppArmor: ~nanoseconds per syscall (kernel-space)
- Monitoring: ~10ms per check (runs periodically, not during rendering)

Rendering performance is **unchanged**.

## Legal Considerations

See `EULA-Analysis.md` for full assessment of Foundry's EULA claims.

**Summary:**
- EULA grants "irrevocable authorization" for data collection (Clause 19.3)
- Blocking telemetry may technically violate EULA acceptance
- However, enforceability of such clauses is questionable in many jurisdictions
- No reports of Foundry taking action against users who block telemetry
- Offline/air-gapped use is common in VFX industry (studios routinely block telemetry)

**Recommendation:** Use blocking methods and accept minimal legal risk. Enterprise/studio users should consult legal counsel.

## References

- **Investigation methodology:** `Claude_2025-10-25.md` (full conversation log)
- **Packet capture analysis:** `nuke_foundry_analysis.md` (20-minute capture breakdown)
- **Basic blocking:** `block_nuke_telemetry.sh` (hosts file method)
- **EULA details:** `EULA-Analysis.md` (privacy clauses)
- **Master documentation:** `Foundry-Nuke-Monitoring.md` (conclusory report)

## Contributing

Discovered new telemetry endpoints? Improved blocking methods?

Document findings in this project and update:
1. This file (Advanced-Blocking-Methods.md)
2. Master doc (Foundry-Nuke-Monitoring.md)
3. CLAUDE.md (investigation areas)

Help the VFX community maintain privacy and informed consent.

---

**Last updated:** 2025-11-25
**Nuke version tested:** 15.2v6 (build 15.2.375648)
**OS:** Arch Linux (kernel 6.17.4-arch2-1)