moved random shit to documentation folder
This commit is contained in:
parent
11c6849d4a
commit
1ba71a2a14
@ -1,420 +0,0 @@
|
|||||||
# Intercepting and Decrypting Your Own HTTPS Traffic
|
|
||||||
|
|
||||||
## Important Legal and Technical Notice
|
|
||||||
|
|
||||||
**What this document covers:**
|
|
||||||
- ✅ Inspecting YOUR OWN traffic from YOUR OWN software on YOUR OWN computer
|
|
||||||
- ✅ Legally and technically sound methods using SSL/TLS interception
|
|
||||||
- ✅ Educational purposes for privacy research
|
|
||||||
- ✅ Complementing the master investigation in [[Foudry-Nuke-Monitoring#Executive Summary]]
|
|
||||||
|
|
||||||
**What this does NOT do:**
|
|
||||||
- ❌ Brute-force decrypt HTTPS (not possible with modern encryption)
|
|
||||||
- ❌ Intercept other people's traffic (illegal)
|
|
||||||
- ❌ Break into Foundry's servers (illegal)
|
|
||||||
|
|
||||||
**Legal basis:** You have the right to inspect data YOUR software sends from YOUR computer.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Why You Can't Brute Force HTTPS
|
|
||||||
|
|
||||||
**Technical reality:**
|
|
||||||
- Modern TLS uses 2048-4096 bit RSA or 256-bit ECC keys
|
|
||||||
- Brute-forcing would take **billions of years** with current hardware
|
|
||||||
- Even nation-states with supercomputers cannot brute-force TLS
|
|
||||||
- Quantum computers (not yet practical) would still take months/years
|
|
||||||
|
|
||||||
**The only way to decrypt HTTPS is:**
|
|
||||||
1. **Intercept during handshake** (before encryption) - This is what we'll do
|
|
||||||
2. **Compromise the server** (illegal and we're not doing this)
|
|
||||||
3. **Extract keys from memory** (requires root access to Nuke process - possible but advanced)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Method 1: SSL/TLS Interception Proxy (Recommended)
|
|
||||||
|
|
||||||
For master timeline context see [[Foudry-Nuke-Monitoring#Phase-4-Gap-Analysis-and-Troubleshooting]].
|
|
||||||
|
|
||||||
### How It Works
|
|
||||||
|
|
||||||
```
|
|
||||||
Nuke → Your Proxy → Foundry Servers
|
|
||||||
↓
|
|
||||||
Decrypted logs
|
|
||||||
```
|
|
||||||
|
|
||||||
Your proxy acts as a "man-in-the-middle" between Nuke and Foundry:
|
|
||||||
1. Nuke connects to proxy (encrypted)
|
|
||||||
2. Proxy decrypts, logs the data
|
|
||||||
3. Proxy re-encrypts and forwards to Foundry
|
|
||||||
4. You get plaintext logs of what Nuke sent
|
|
||||||
|
|
||||||
**This works because:**
|
|
||||||
- You control both endpoints (Nuke and the proxy)
|
|
||||||
- Nuke is configured to trust your proxy's certificate
|
|
||||||
- It's YOUR traffic on YOUR machine
|
|
||||||
|
|
||||||
### Tool: mitmproxy
|
|
||||||
|
|
||||||
See [[Foudry-Nuke-Monitoring#Monitoring-Infrastructure-Setup]] for complementary automation scripts.
|
|
||||||
|
|
||||||
**Install mitmproxy:**
|
|
||||||
```bash
|
|
||||||
sudo pacman -S mitmproxy
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 1: Start mitmproxy**
|
|
||||||
```bash
|
|
||||||
# Start in transparent mode
|
|
||||||
sudo mitmproxy --mode transparent --showhost -w nuke_traffic.mitm
|
|
||||||
```
|
|
||||||
|
|
||||||
Or use the web interface:
|
|
||||||
```bash
|
|
||||||
sudo mitmweb --mode transparent --showhost
|
|
||||||
# Opens browser at http://127.0.0.1:8081
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 2: Configure iptables to redirect traffic**
|
|
||||||
|
|
||||||
Create a script to redirect Foundry traffic through the proxy:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
#!/bin/bash
|
|
||||||
# redirect_to_proxy.sh
|
|
||||||
|
|
||||||
# Redirect traffic to Honeycomb through mitmproxy
|
|
||||||
sudo iptables -t nat -A OUTPUT -p tcp -d 52.205.16.9 --dport 443 -j REDIRECT --to-port 8080
|
|
||||||
|
|
||||||
# Redirect traffic to learn.foundry.com
|
|
||||||
sudo iptables -t nat -A OUTPUT -p tcp -d 52.50.232.31 --dport 443 -j REDIRECT --to-port 8080
|
|
||||||
|
|
||||||
# Redirect any other foundry.com traffic
|
|
||||||
sudo iptables -t nat -A OUTPUT -p tcp -d foundry.com --dport 443 -j REDIRECT --to-port 8080
|
|
||||||
|
|
||||||
echo "Traffic redirected to mitmproxy on port 8080"
|
|
||||||
echo "To undo: sudo iptables -t nat -F"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 3: Install mitmproxy certificate in Nuke**
|
|
||||||
|
|
||||||
Nuke needs to trust the mitmproxy certificate:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Start mitmproxy to generate certificate
|
|
||||||
mitmproxy &
|
|
||||||
sleep 2
|
|
||||||
killall mitmproxy
|
|
||||||
|
|
||||||
# Certificate is at ~/.mitmproxy/mitmproxy-ca-cert.pem
|
|
||||||
# Copy to system trust store
|
|
||||||
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /etc/ca-certificates/trust-source/anchors/mitmproxy.crt
|
|
||||||
sudo trust extract-compat
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 4: Launch Nuke and capture traffic**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Start mitmproxy with logging
|
|
||||||
mitmweb --mode transparent --showhost -w ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).mitm
|
|
||||||
|
|
||||||
# In another terminal: redirect traffic
|
|
||||||
./redirect_to_proxy.sh
|
|
||||||
|
|
||||||
# Launch Nuke and use normally
|
|
||||||
|
|
||||||
# When done, restore iptables
|
|
||||||
sudo iptables -t nat -F
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 5: View captured traffic**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Replay captured session
|
|
||||||
mitmproxy -r nuke_decrypted_*.mitm
|
|
||||||
|
|
||||||
# Export to JSON for analysis
|
|
||||||
mitmdump -r nuke_decrypted_*.mitm -w nuke_traffic.json
|
|
||||||
|
|
||||||
# Or use the web interface to browse requests/responses
|
|
||||||
```
|
|
||||||
|
|
||||||
**What you'll see:**
|
|
||||||
- Full HTTP headers (User-Agent, API keys if any)
|
|
||||||
- Complete request/response bodies (JSON telemetry data)
|
|
||||||
- Timing information
|
|
||||||
- All the data Nuke sends to Honeycomb/Sentry
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Method 2: Extract TLS Keys from Nuke Process
|
|
||||||
|
|
||||||
Background on why this matters: [[Foudry-Nuke-Monitoring#Data-We-Cannot-See-Encrypted]].
|
|
||||||
|
|
||||||
### How It Works
|
|
||||||
|
|
||||||
When Nuke establishes TLS connections, the encryption keys exist briefly in memory. We can extract them and use them to decrypt packet captures.
|
|
||||||
|
|
||||||
**This is ADVANCED and may not work if Nuke uses certificate pinning.**
|
|
||||||
|
|
||||||
### Tool: sslkeylog
|
|
||||||
|
|
||||||
**Step 1: Install sslkeylog**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Install from AUR
|
|
||||||
yay -S sslkeylog-git
|
|
||||||
# or build from source: https://github.com/adulau/sslkeylog
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 2: Use LD_PRELOAD to capture keys**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Set environment variable to log keys
|
|
||||||
export SSLKEYLOGFILE=~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log
|
|
||||||
|
|
||||||
# Launch Nuke with LD_PRELOAD
|
|
||||||
LD_PRELOAD=/usr/lib/libsslkeylog.so /path/to/Nuke15.2v6/Nuke
|
|
||||||
|
|
||||||
# Or if Nuke is already running, inject into process (requires root):
|
|
||||||
sudo gdb -p $(pgrep -f Nuke) -batch -ex "call setenv(\"SSLKEYLOGFILE\", \"$SSLKEYLOGFILE\", 1)"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 3: Capture traffic while Nuke runs**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo tcpdump -i any -w nuke_for_decrypt.pcap 'host honeycomb.io or host foundry.com'
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 4: Decrypt with Wireshark**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Open in Wireshark
|
|
||||||
wireshark nuke_for_decrypt.pcap
|
|
||||||
|
|
||||||
# Configure to use key log:
|
|
||||||
# Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename
|
|
||||||
# Browse to ~/Documents/obsidian-vault/2-projects/Nuke-monitoring/dump/sslkeys.log
|
|
||||||
|
|
||||||
# Wireshark will now decrypt all TLS traffic!
|
|
||||||
```
|
|
||||||
|
|
||||||
**What you'll see:**
|
|
||||||
- Decrypted HTTP/2 or HTTP/1.1 requests
|
|
||||||
- Full JSON payloads sent to Honeycomb
|
|
||||||
- API calls to Sentry
|
|
||||||
- All telemetry data in plaintext
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Method 3: HTTP Library Hooking (Most Reliable)
|
|
||||||
|
|
||||||
See also [[Foudry-Nuke-Monitoring#Technical-Architecture]] for service overview.
|
|
||||||
|
|
||||||
### How It Works
|
|
||||||
|
|
||||||
Hook into the SSL/HTTP libraries Nuke uses to log traffic BEFORE encryption.
|
|
||||||
|
|
||||||
**This intercepts at the application layer, so it works even with certificate pinning.**
|
|
||||||
|
|
||||||
### Tool: frida (Dynamic instrumentation)
|
|
||||||
|
|
||||||
**Step 1: Install frida**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo pacman -S frida frida-tools
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 2: Create hooking script**
|
|
||||||
|
|
||||||
Create `hook_nuke_ssl.js`:
|
|
||||||
|
|
||||||
```javascript
|
|
||||||
// Hook OpenSSL SSL_write to log data BEFORE encryption
|
|
||||||
Interceptor.attach(Module.findExportByName(null, "SSL_write"), {
|
|
||||||
onEnter: function(args) {
|
|
||||||
var ssl = args[0];
|
|
||||||
var buf = args[1];
|
|
||||||
var len = args[2].toInt32();
|
|
||||||
|
|
||||||
// Read the buffer contents
|
|
||||||
var data = Memory.readByteArray(buf, len);
|
|
||||||
|
|
||||||
// Try to parse as UTF-8
|
|
||||||
try {
|
|
||||||
var str = Memory.readUtf8String(buf, len);
|
|
||||||
console.log("\n[SSL_write] Sending " + len + " bytes:");
|
|
||||||
console.log(str);
|
|
||||||
} catch(e) {
|
|
||||||
console.log("\n[SSL_write] Sending " + len + " bytes (binary data)");
|
|
||||||
console.log(hexdump(data, { ansi: true }));
|
|
||||||
}
|
|
||||||
|
|
||||||
// Log to file
|
|
||||||
var file = new File("/tmp/nuke_ssl_log.txt", "a");
|
|
||||||
file.write(str + "\n---\n");
|
|
||||||
file.close();
|
|
||||||
}
|
|
||||||
});
|
|
||||||
|
|
||||||
// Hook SSL_read to log received data AFTER decryption
|
|
||||||
Interceptor.attach(Module.findExportByName(null, "SSL_read"), {
|
|
||||||
onLeave: function(retval) {
|
|
||||||
if(retval.toInt32() > 0) {
|
|
||||||
var len = retval.toInt32();
|
|
||||||
var buf = this.context.rsi; // Second argument (buffer)
|
|
||||||
|
|
||||||
try {
|
|
||||||
var str = Memory.readUtf8String(ptr(buf), len);
|
|
||||||
console.log("\n[SSL_read] Received " + len + " bytes:");
|
|
||||||
console.log(str);
|
|
||||||
} catch(e) {
|
|
||||||
console.log("\n[SSL_read] Received " + len + " bytes (binary)");
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
});
|
|
||||||
|
|
||||||
console.log("[*] SSL hooks installed. Monitoring Nuke SSL traffic...");
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 3: Attach to Nuke process**
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Find Nuke PID
|
|
||||||
NUKE_PID=$(pgrep -f Nuke)
|
|
||||||
|
|
||||||
# Attach frida
|
|
||||||
frida -p $NUKE_PID -l hook_nuke_ssl.js -o nuke_decrypted_$(date +%Y-%m-%d_%H-%M-%S).log
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 4: Use Nuke normally**
|
|
||||||
|
|
||||||
All SSL/TLS traffic will be logged in plaintext to:
|
|
||||||
- Console output
|
|
||||||
- `/tmp/nuke_ssl_log.txt`
|
|
||||||
- `nuke_decrypted_*.log`
|
|
||||||
|
|
||||||
**What you'll see:**
|
|
||||||
- Exact JSON payloads sent to Honeycomb
|
|
||||||
- HTTP headers (User-Agent, Authorization, API keys)
|
|
||||||
- Sentry crash report contents
|
|
||||||
- ALL telemetry data before encryption
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Method 4: Patch Nuke Binary (ADVANCED - NOT RECOMMENDED)
|
|
||||||
|
|
||||||
**This involves modifying Nuke's executable to disable certificate pinning or add logging. This is complex, may violate EULA, and can break Nuke.**
|
|
||||||
|
|
||||||
**Only mention for completeness - NOT recommended.**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Recommended Approach
|
|
||||||
|
|
||||||
Cross-reference: [[Foudry-Nuke-Monitoring#Recommendations]].
|
|
||||||
|
|
||||||
**I recommend Method 1 (mitmproxy) or Method 3 (frida) depending on your technical comfort:**
|
|
||||||
|
|
||||||
| Method | Difficulty | Reliability | Notes |
|
|
||||||
|--------|-----------|-------------|-------|
|
|
||||||
| mitmproxy | Medium | Good | May fail if Nuke uses certificate pinning |
|
|
||||||
| sslkeylog | Hard | Medium | Requires LD_PRELOAD or GDB injection |
|
|
||||||
| frida | Medium-Hard | Excellent | Works even with certificate pinning |
|
|
||||||
|
|
||||||
**Start with mitmproxy.** If Nuke rejects the certificate (connection errors), fall back to frida.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What You'll Discover
|
|
||||||
|
|
||||||
Once you decrypt the traffic, you'll see the **exact contents** of the 17KB Honeycomb payload, including:
|
|
||||||
|
|
||||||
**Likely contents (based on EULA and typical telemetry):**
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"telemetry_version": "1.0",
|
|
||||||
"timestamp": "2025-10-25T12:34:56Z",
|
|
||||||
"session_id": "abc123...",
|
|
||||||
|
|
||||||
"user": {
|
|
||||||
"license_id": "...",
|
|
||||||
"license_type": "commercial",
|
|
||||||
"email_domain": "example.com",
|
|
||||||
"user_id": "hashed_id"
|
|
||||||
},
|
|
||||||
|
|
||||||
"system": {
|
|
||||||
"os": "Linux",
|
|
||||||
"os_version": "6.17.4-arch2-1",
|
|
||||||
"cpu": "AMD Ryzen ...",
|
|
||||||
"gpu": "NVIDIA RTX ...",
|
|
||||||
"ram_gb": 64,
|
|
||||||
"disk_space_gb": 2048,
|
|
||||||
"locale": "en_US",
|
|
||||||
"timezone": "America/Los_Angeles"
|
|
||||||
},
|
|
||||||
|
|
||||||
"location": {
|
|
||||||
"country": "US",
|
|
||||||
"region": "California",
|
|
||||||
"city": "Los Angeles",
|
|
||||||
"ip_hash": "hashed_ip"
|
|
||||||
},
|
|
||||||
|
|
||||||
"software": {
|
|
||||||
"nuke_version": "15.2v6",
|
|
||||||
"plugins": ["Cryptomatte", "OpticalFlares", ...],
|
|
||||||
"python_version": "3.9.2"
|
|
||||||
},
|
|
||||||
|
|
||||||
"usage": {
|
|
||||||
"session_start": "2025-10-25T12:00:00Z",
|
|
||||||
"session_duration_seconds": 7200,
|
|
||||||
"nodes_created": {
|
|
||||||
"Read": 45,
|
|
||||||
"Write": 12,
|
|
||||||
"Merge": 23,
|
|
||||||
"Grade": 15,
|
|
||||||
...
|
|
||||||
},
|
|
||||||
"tools_used": ["Viewer", "Curve Editor", "Node Graph"],
|
|
||||||
"render_count": 5,
|
|
||||||
"render_frames_total": 240,
|
|
||||||
"scripts_executed": 12
|
|
||||||
},
|
|
||||||
|
|
||||||
"performance": {
|
|
||||||
"average_fps": 24.5,
|
|
||||||
"peak_memory_mb": 8192,
|
|
||||||
"crash_count": 0,
|
|
||||||
"error_count": 3
|
|
||||||
},
|
|
||||||
|
|
||||||
"errors": [
|
|
||||||
{
|
|
||||||
"type": "FileNotFound",
|
|
||||||
"message": "Could not load /path/to/missing_file.exr",
|
|
||||||
"timestamp": "2025-10-25T13:45:12Z"
|
|
||||||
}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
**This will definitively answer:**
|
|
||||||
- ✅ Is email domain transmitted? (Yes/No + exact field)
|
|
||||||
- ✅ Is geographic location sent? (Yes/No + granularity)
|
|
||||||
- ✅ What system info is collected? (Exact fields)
|
|
||||||
- ✅ What usage data is tracked? (Which features, how often)
|
|
||||||
- ✅ Are file paths included? (Privacy concern if yes)
|
|
||||||
|
|
||||||
For broader context on unanswered questions, see [[Foudry-Nuke-Monitoring#Gap-Analysis-and-Troubleshooting]].
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Automated Decryption Script
|
|
||||||
|
|
||||||
I'll create a wrapper script that tries mitmproxy first, falls back to frida if needed:
|
|
||||||
} need ensure anchor correct; actual section
|
|
||||||
132
docs/quick-start.md
Normal file
132
docs/quick-start.md
Normal file
@ -0,0 +1,132 @@
|
|||||||
|
# Quick Start Guide for Nuke Telemetry Blocking
|
||||||
|
|
||||||
|
> This guide walks a beginner through installing the required tools, running the monitoring scripts, and blocking telemetry from The Foundry’s **Nuke** compositor. All commands are written for an Arch‑Linux system.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Prerequisites
|
||||||
|
|
||||||
|
| Package | Purpose |
|
||||||
|
|---------|---------|
|
||||||
|
| `tcpdump` | Capture packets for analysis |
|
||||||
|
| `iptables` / `nftables` | Firewall rules used by the scripts |
|
||||||
|
| `notify-send` (optional) | Desktop notifications from the monitor script |
|
||||||
|
| `curl`, `nslookup` | Verify that blocks are working |
|
||||||
|
|
||||||
|
Install them with pacman:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo pacman -S --needed tcpdump iptables nftables libnotify curl nslookup
|
||||||
|
```
|
||||||
|
|
||||||
|
> The scripts ship with a **--help** flag – run any script with `-h` to see its options.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Quick Reference Table
|
||||||
|
|
||||||
|
| Script | What it does | Typical command |
|
||||||
|
|--------|--------------|----------------|
|
||||||
|
| `scripts/firewall_block_nuke.sh` | Adds kernel‑level rules that reject outbound connections to Foundry telemetry IPs. | `sudo bash scripts/firewall_block_nuke.sh`
|
||||||
|
| `block_nuke_telemetry.sh` | Modifies `/etc/hosts` so the domains resolve to 127.0.0.1. | `bash block_nuke_telemetry.sh`
|
||||||
|
| `scripts/monitor_nuke_network.sh` | Continuously watches Nuke processes and logs any external connections. | `bash scripts/monitor_nuke_network.sh --continuous`
|
||||||
|
| `scripts/dns_sinkhole_config.sh` | Generates configuration snippets for Pi‑Hole / dnsmasq that block Foundry domains. | `bash scripts/dns_sinkhole_config.sh`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Installation & Setup
|
||||||
|
|
||||||
|
1. **Clone the repository** (if you haven’t already):
|
||||||
|
```bash
|
||||||
|
git clone https://github.com/your-org/block-nuke-telemetry.git
|
||||||
|
cd block-nuke-telemetry
|
||||||
|
```
|
||||||
|
2. **Make scripts executable** – they should already be, but just in case:
|
||||||
|
```bash
|
||||||
|
chmod +x *.sh scripts/*.sh
|
||||||
|
```
|
||||||
|
3. **Run the firewall blocker (recommended first step)**:
|
||||||
|
```bash
|
||||||
|
sudo bash scripts/firewall_block_nuke.sh
|
||||||
|
```
|
||||||
|
> This writes rules to `/etc/iptables/iptables.rules` or `/etc/nftables.conf`. Use `--status` to verify.
|
||||||
|
4. **Apply the hosts‑file block** (optional but adds a second layer):
|
||||||
|
```bash
|
||||||
|
bash block_nuke_telemetry.sh
|
||||||
|
```
|
||||||
|
5. **(Optional) Generate DNS sinkhole configs** if you run Pi‑Hole or dnsmasq:
|
||||||
|
```bash
|
||||||
|
bash scripts/dns_sinkhole_config.sh > ~/pi-hole-dns.conf
|
||||||
|
```
|
||||||
|
Then add the generated lines to your DNS server.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Basic Usage
|
||||||
|
|
||||||
|
### 4.1 Monitoring Nuke in Real Time
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Run in a terminal; press Ctrl+C to stop
|
||||||
|
bash scripts/monitor_nuke_network.sh --continuous
|
||||||
|
```
|
||||||
|
The script prints lines like:
|
||||||
|
|
||||||
|
```
|
||||||
|
[2025-11-27 14:32:10] ALERT: Nuke process (PID 867114) connected to api.honeycomb.io:443
|
||||||
|
```
|
||||||
|
It also writes a log file `nuke_telemetry_alerts.log` that can be tail‑viewed.
|
||||||
|
|
||||||
|
### 4.2 Capturing Packets for Investigation
|
||||||
|
|
||||||
|
If you want to capture traffic yourself, use the following command (you may need sudo):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo tcpdump -i any -w nuke_foundry_capture.pcap 'host api.honeycomb.io or host learn.foundry.com'
|
||||||
|
```
|
||||||
|
Stop with `Ctrl+C` and analyze later.
|
||||||
|
|
||||||
|
### 4.3 Verifying the Blocks
|
||||||
|
|
||||||
|
After applying firewall/hosts rules, confirm that DNS resolves to localhost and that connections fail:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# DNS resolution should return 127.0.0.1
|
||||||
|
nslookup api.honeycomb.io
|
||||||
|
# Connection attempt should timeout or be refused
|
||||||
|
curl -I https://api.honeycomb.io --max-time 5
|
||||||
|
```
|
||||||
|
You should see `Connection timed out` or a refusal.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Troubleshooting Common Issues
|
||||||
|
|
||||||
|
| Symptom | Likely Cause | Fix |
|
||||||
|
|---------|--------------|-----|
|
||||||
|
| Help menu in Nuke doesn’t load | `learn.foundry.com` is blocked | Temporarily comment out the hosts‑file entry or use a VPN that bypasses DNS filtering |
|
||||||
|
| Crash reports are not sent | Sentry domain blocked | Keep the hosts block but allow `sentry.foundry.com` if you need support |
|
||||||
|
| Nuke fails to start | Firewall rule accidentally blocks localhost | Ensure rules only target external IPs. Check with `sudo iptables -L OUTPUT -v -n`. |
|
||||||
|
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Further Reading
|
||||||
|
|
||||||
|
* **Advanced Blocking Methods** – detailed explanation of each technique: [Advanced‑Blocking‑Methods.md](../analysis/Advanced-Blocking-Methods.md)
|
||||||
|
* **Packet Capture Analysis** – the raw 20‑minute capture and findings: [nuke_foundry_analysis.md](../analysis/nuke_foundry_analysis.md)
|
||||||
|
* **Full Investigation Report** – legal, privacy, and mitigation summary: [Foudry-Nuke-Monitoring.md](../analysis/Foudry-Nuke-Monitoring.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Appendix – Quick‑Start Script Flags
|
||||||
|
|
||||||
|
| Flag | Meaning |
|
||||||
|
|------|---------|
|
||||||
|
| `--continuous` | Keep the monitor running until stopped with Ctrl+C |
|
||||||
|
| `--status` | Show current firewall rule status |
|
||||||
|
| `--restore` | Remove firewall rules added by `firewall_block_nuke.sh` |
|
||||||
|
| `-h`, `--help` | Display usage information |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Enjoy a privacy‑respectful Nuke workflow!**
|
||||||
Loading…
x
Reference in New Issue
Block a user