Detection Guidance: Auditing Your Homelab for Exposed MCP Servers

The Problem

The Model Context Protocol (MCP) was designed for capability, not security. When self-hosted agents expose endpoints on your network, they can be discovered and abused — Trend Micro documented nearly 1,500 exposed servers as of April 2026. This guidance is a hands-on checklist for homelab operators running Ollama, custom MCP servers, or agent orchestration frameworks locally.

1. Auditing Your Own Network for Exposed MCP Endpoints

Start by mapping which services are listening on which ports, then cross-reference against known MCP implementations.

List local listeners:

ss -tlnp | grep -E ':(11434|8080|8765|3000)'
nmap -sT -p 1-65535 localhost

MCP servers can bind to any port. Check ollama serve, Docker Compose ports mappings, systemd service files for OLLAMA_HOST environment variables, and reverse proxy configs (Caddy, Traefik).

Check external exposure:

nmap -sT <your-public-ip> --top-ports 1000

If port 11434 is reachable publicly, you have a critical exposure. Every open MCP endpoint without authentication is effectively a credential-free entry point — attackers can query your agents and execute tool calls with full system access.

Audit Docker containers:

docker ps --format "table {{.Names}}\t{{.Ports}}" | grep -iE 'ollama|mcp|agent'

Many Docker Compose files default to binding all interfaces (0.0.0.0) when no interface is specified, making services network-wide without explicit intent.

2. Port Scanning and Service Fingerprinting for MCP Targets

Once you know which ports are open, fingerprint what's running on them.

Identify Ollama instances:

curl -s http://<host>:11434/api/tags | jq '.models[].name'

A model list confirms an active instance — and arbitrary model execution without authentication (CVE-2025-15063, CVSS 9.8).

Identify Anthropic/Claude agent endpoints:

# Check for local Claude agent deployments (common ports)
for port in 11434 3001 8765; do curl -s "http://localhost:${port}/v1/models"; done
# Search config files for Anthropic API keys
grep -r "sk-ant-" /etc/ollama/.env ~/.config/claude-code/ 2>/dev/null

Identify custom MCP servers (LangChain, LiteLLM):

nmap -sV --script=http-headers <host> -p 11434,8080,8765,3000
curl -N http://<host>:8765/sse   # SSE endpoint check

If the server returns event: message or event: text, you've found an active MCP Server-to-Client (S2C) SSE endpoint.

Check for credential leakage:

find /etc/ollama ~/.config -name "*.env" -o -name "config.json" | xargs grep -lE "(API_KEY|SECRET)" 2>/dev/null
docker exec <container> cat /.env 2>/dev/null

48% of scanned MCP configurations store secrets in plaintext. If you find API keys exposed, your network is only as secure as your local machine — dangerous if it also serves web traffic or runs developer tools that enable lateral movement.

3. Authentication Hardening Steps

MCP assumes a trusted local environment. That breaks when agents are exposed beyond localhost.

Bind to localhost where possible:

OLLAMA_HOST=127.0.0.1 ollama serve

For remote access, use SSH tunneling instead of opening ports directly:

ssh -L 11434:localhost:11434 user@homelab-host

Ollama-specific hardening:

• Enable HTTPS with self-signed or Let's Encrypt (supported since v0.5)
• Add reverse proxy authentication for externally accessible endpoints
• Set OLLAMA_ORIGINS to restrict which hosts can connect
• Use OLLAMA_API_KEY to require authentication for API requests

Anthropic/Claude agents:

• Rotate any exposed API keys — assume compromised if endpoint was open to LAN
• Use per-project tokens instead of master keys with broad permissions
• Enable request logging and usage quotas to detect unauthorized queries

Custom agent deployments:

• Wrap MCP servers behind reverse proxies requiring authentication (basic, token, OAuth)
• Drop external traffic at the firewall before it reaches service ports
• Use system prompts that reject tool calls from unauthenticated sessions

Credential management:

chmod 600 /etc/ollama/.env ~/.config/mcp-server/config.json
chown ollama:ollama /etc/ollama/.env

Use a secrets manager (pass, Docker secrets) instead of plaintext configs. The goal isn't perfection — it's raising the cost of casual credential theft.

4. Network Segmentation Recommendations

The most robust protection is network-level isolation: keep agents in their own segment.

Isolate agent services on a separate VLAN or Docker network:

nft add rule inet firewall forward iif docker-agents oif docker-agents accept
nft add rule inet firewall forward iif lan oif docker-agents drop
nft add rule inet firewall forward iif docker-agents oif wan drop

Even if a service binds to 0.0.0.0, firewall rules block external traffic before it reaches the agent.

Use Docker bridge instead of host network mode:

Many homelab operators use network_mode: host for simplicity — this bypasses all Docker isolation. Use explicit port mappings only when needed:

services:
  ollama:
    ports:
      - "127.0.0.1:11434:11434"   # Loopback-only
    network_mode: bridge

The 127.0.0.1: prefix prevents external access even if the port is listed in docker ps. This single change is one of the most impactful hardening steps for Ollama operators.

Implement egress filtering:

nft add rule inet firewall forward oif docker-agents ip daddr ! 192.168.0.0/16 drop "no external access for agents"

A compromised agent that can call AWS/GCP APIs poses far more risk than one running local prompts only.

Practical Checklist Summary

• [ ] Verify Ollama isn't open externally: curl -s http://localhost:11434/api/tags
• [ ] Change Docker containers from 0.0.0.0:<port> to 127.0.0.1:<port> where external access isn't required
• [ ] Audit configs for leaked API keys (.env, JSON, systemd files)
• [ ] Add reverse proxy auth or SSH tunneling for remotely accessible MCP endpoints
• [ ] Implement firewall rules denying external-to-agent traffic
• [ ] Use separate Docker networks/VLANs instead of host network mode
• [ ] Restrict egress from agent containers to only needed services

Taken From

Original lab-note draft reviewed and published after technical review. Key sources:

• Trend Micro — Exposing MCP Servers to the Open Internet: A Growing Risk (April 2026)
• Ollama Security Advisory — MCP Server Critical Remote Code Execution Vulnerability (January 9, 2026)
• Aembit — How to Make an MCP Safe: Best Practices for AI Agent Security
• CyberDesserts — AI Agent Security Risks (February 2026)

The takeaway: the convenience that made MCP attractive (zero-config, local-first) also makes it trivially exploitable. Bind to localhost where possible, segment your network, and audit credentials. Every step raises the cost for casual exploitation.