Custom URL feed

The four platform-curated feeds (FireHOL, Tor, AbuseIPDB) cover broad threats. Your tenant likely has its own threat data — IPs from past incidents, allowlists, customer-specific bad-actor lists. Custom URL feeds let you bring that data in.

How it works

You serve a list of IPs / CIDR ranges from a URL the platform can reach. The platform polls the URL on a configurable cadence; the contents become a tenant-scoped threat feed.

Format

The platform expects plain text. One entry per line. Comments allowed:

# IPs from incident IR-2024-09 — known-bad C2 servers
203.0.113.45
203.0.113.46
198.51.100.0/24

# Suspicious residential IPs flagged by support
192.0.2.123

Each line is:

An IPv4 address (203.0.113.45).
An IPv4 CIDR range (198.51.100.0/24).
An IPv6 address.
An IPv6 CIDR range.
A comment (starts with #).
An empty line.

Anything else fails parsing; the platform logs the parse error in audit + falls back to the previous-good content.

Add a custom feed

Threat intelligence → Feeds → Add feed → Custom URL.

Configure:

Name — your label ("Cymmetri internal blocklist", "IR-2024-09 IPs").
URL — where the platform fetches from. HTTPS required. The URL doesn't need to be public — IP-allowlist the platform's outbound IPs (visible in Settings → Network → Platform outbound IPs).
Auth (optional) — Basic Auth or a Bearer token, if your URL is gated. The credential is stored encrypted; never visible after entry.
Update cadence — 5min / 15min / 1h / daily. Picks the polling rhythm.
Score weight — same dial as platform feeds. Default 25; tune for your tenant.

Click Add. The platform fetches the URL immediately as a test; saves on success; reports error on failure.

Hosting the URL

Common patterns:

S3 bucket with a Lambda that updates the file. Cheap; reliable.
A small endpoint on your own backend that serves the list from a database. Useful if the list updates frequently.
A static file in your team's internal storage with an allowlist on the platform's outbound IPs.

Don't:

Host the URL on the same tenant whose sign-ins it'd block (chicken-and-egg).
Serve from a slow / flaky URL — repeated fetch failures degrade your protection.

Refresh-failure handling

If the URL fetches fail for 3 consecutive intervals:

The feed's status flips to error.
security.threat_feed_fetch_failed lands in audit.
The platform keeps using the LAST successfully-fetched content.
Risk scoring continues with stale data; no users get unblocked simply because the feed went stale.

To "force" the platform to re-fetch outside the cadence — open the feed's detail page → Refresh now.

When a feed entry is added

You add an IP to the served list. Within the cadence window (5 minutes if you configured that), the platform's next fetch picks it up. The next sign-in from that IP includes the feed's score weight in the risk calculation.

If you need IMMEDIATE effect (an active incident), force-refresh from the feed's detail page. The platform refetches within seconds.

When a feed entry is removed

You remove an IP from the served list. Within the cadence window, the platform stops counting hits on that IP. Sign-ins from the IP normalise back to whatever their score was without the custom feed.

Audit

Custom URL feed events:

security.threat_feed_added — feed created.
security.threat_feed_updated — config edited.
security.threat_feed_refreshed — successful fetch (with delta: N entries added, M removed).
security.threat_feed_fetch_failed — fetch error (with the specific HTTP / TLS error).

For "did the feed pick up my new IPs?" verification, filter audit on security.threat_feed_refreshed and check the entry-count delta.

Common patterns

Incident-response blocklist

After an incident, you have a list of attacker IPs. Spin up an S3 bucket with the list; configure as a custom feed with weight 50 (high). Sign-ins from those IPs are effectively blocked.

After the incident has aged (e.g., 6 months), remove the feed or reduce the weight to a tracking-only level.

Threat-feed federation

You're part of an industry threat-sharing network. They publish a feed URL; you configure it as a custom feed. Their updates propagate to you.

Internal-only allowlist (negative pattern)

You want to ALLOW certain IPs unconditionally. The custom URL feed is the wrong tool — it adds to the risk score; doesn't subtract.

For allowlists, use Threat → Whitelists (a different surface).

When NOT to use custom URL feeds

For tiny lists (< 10 IPs). Manually maintain a Whitelist or Blocklist; cheaper than running a URL.
For lists that change every minute. Either too-frequent polling or stale data; consider building a webhook-driven update pattern via a different integration.
For per-application logic. Custom URL feeds are tenant-wide. For "this IP is bad for application X only", use a custom Action on the application's pre-credential-check trigger.