450 lines
14 KiB
Markdown
450 lines
14 KiB
Markdown
# 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)
|