Introduction to Cybora

Cybora provides curated threat intelligence feeds for firewalls and network security devices. The basic idea is simple: your firewall retrieves a feed over HTTPS, imports the indicators into a native object or list, and uses that list in policy.

Cybora is designed to complement your existing security controls. It can help reduce exposure to known malicious infrastructure at the perimeter, but it does not replace IPS, EDR, DNS security, SIEM monitoring, or a reviewed firewall policy.

What Cybora delivers

Cybora publishes firewall-friendly threat intelligence feeds as plain TXT files delivered over HTTPS. The output is intentionally simple: one indicator per line, without vendor-specific wrappers, JSON payloads, or proprietary firewall formats.

Depending on your subscription plan, Cybora can provide coverage for indicator categories such as IPv4 addresses, domains, and URLs. The file format stays the same. What changes is the indicator category in the feed and the native firewall feature that consumes it.

This keeps deployment close to the firewall vendor’s native workflow and avoids custom agents or complex API integrations for the common path. The firewall-specific part is the configuration location inside the firewall, not a Cybora-specific file format.

The usual deployment pattern is:

1. Copy the Cybora HTTPS feed URL for the indicator category covered by your plan.
2. Add the URL to the firewall’s native external list, alias, dynamic list, or threat feed feature.
3. Set a polling interval that matches your Cybora plan and the firewall vendor’s recommendations.
4. Reference the imported list in firewall, DNS, web, or security policy where supported by the platform.
5. Validate that the firewall can fetch the TXT feed, read the entries, and apply the intended action.

Common concepts

Most Cybora deployments share a few concepts:

• A license key identifies the feed subscription. Unless your plan states otherwise, one key is intended for one firewall device or one logical HA edge.
• The feed URL includes the license key and identifies the indicator category and access scope.
• The firewall polls the URL on a recurring schedule.
• The firewall stores the fetched indicators in a native object, list, alias, category, or feed object.
• Policy decides whether matched traffic is blocked, rejected, logged, or only monitored.
• Excessive polling can trigger rate limiting or temporary blocking, so the firewall refresh interval must stay within the allowed plan limits.

Recommended rollout

Start with a controlled rollout. Confirm that the firewall can reach the feed URL, import the expected number of entries, and reference the imported object in policy. Enable logging before you enforce the feed broadly.

Where the firewall supports it, begin with monitoring or a limited policy scope. Review matches, confirm that business-critical traffic is not affected, and then move toward blocking once the behavior is understood.