Skip to content

Forum

AI Assistant
Notifications
Clear all

Showcase: My git repo of allowlists for different Claw agent types

1 Posts
1 Users
0 Reactions
0 Views
(@sec_ops_dave)
Eminent Member
Joined: 2 weeks ago
Posts: 20
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1336]

Hey folks. I've been running various Claw agents in my homelab for a while now, and the biggest headache for me hasn't been the agents themselves—it's been designing and maintaining the firewall rules that keep them secure. Every runtime seems to request the world by default, but in practice, they need surprisingly little.

I got tired of manually comparing logs and vendor docs every time I set up a new agent type or an update changed something. So, I started a git repo to track minimal, working allowlists for different agent categories. The goal is to map what they *actually* need to function versus the huge netblocks they often request.

Here's a snippet from my `networking.yml` for a basic "web scraper / fetcher" type agent running in an isolated VLAN. It only needs outbound HTTP/S to specific targets, and DNS.

```yaml
agent_type: web_fetcher
required_outbound:
- protocol: tcp
port: 53 # DNS
destinations: [ "192.168.10.5" ] # Internal DNS server
- protocol: udp
port: 53
destinations: [ "192.168.10.5" ]
- protocol: tcp
port: 443
destinations: [ "0.0.0.0/0" ] # Ideally you'd lock this down to specific CDN ranges
notes: >
No inbound rules required. Agent initiates all connections.
This list assumes the agent runtime (e.g., the Claw node) is updated via a separate, more privileged management network.
```

The repo is structured by agent function:
* **Data Fetchers** (like above)
* **Code Analysis** agents (need access to internal git, package registries)
* **Action/API** agents (need precise egress to specific SaaS APIs)
* **Internal Processors** (often need only localhost or a message bus)

Key principles I follow:
* Start with a default-deny posture in the agent's network/VLAN.
* Log all denied packets initially to build the list.
* Use specific IP ranges or FQDNs (with DNS sinkholing) over `0.0.0.0/0`.
* Separate the agent runtime management traffic (updates, telemetry) from the agent's operational traffic, often on different VLANs.

I'm hoping this can be a community resource. I'd love to get contributions or critiques—especially if you've found ways to further tighten rules for common runtimes, or have run into issues with specific updates breaking connectivity.

You can find the repo here: [LINK_REDACTED_FOR_FORUM_POST]. Pull requests and issues are welcome.

-- Dave


Segregate or die.


   
Quote