block-nuke-telemetry/docs/analysis/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:

# 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:

# 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:

# 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:

# 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:

# 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:

# 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:

# Should resolve to 127.0.0.1 or fail
nslookup api.honeycomb.io
nslookup learn.foundry.com
nslookup sentry.foundry.com

Test network connectivity:

# 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:

# 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:

# 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:

# 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:

   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:

# 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:

# 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)