A single IP blocklist is not enough to manage today's attack sources and organisational exceptions.
IP reputation is not a problem simple enough to solve with one list. DDoS sources, SSH brute-force attempts, web application attacks, phishing infrastructure, open proxy networks and spam origins all come from different data sets. Relying on a single blocklist covers only a fraction of these attack classes.
Enterprise security teams routinely produce lists from their own SOC sources, closed networks, industry sharing groups or proprietary threat-intelligence providers. Feeding those lists into the WAAP decision pipeline becomes difficult when strict API quotas, closed product architectures or manual rule overhead stand in the way. In on-premises and sovereign-cloud deployments, keeping this control in-house is critical.
IP reputation changes over time. An IP that was an attack source yesterday may belong to a legitimate user today, or a business partner may have been inadvertently added to a community list. Without whitelist precedence and fast exception management, IP reputation can easily become a business-continuity problem.
Writing separate manual rules for every attack category is also unsustainable. Categories such as DDoS, port scan, brute force and web application attack should be individually selectable. The security team should focus on the question "which attack class am I addressing, and with which action?" rather than "which list arrived?"
TR7's approach turns IP reputation into a manageable WAAP control through a central feed, external URL sources, user lists, category-based classification and whitelist precedence.
Our approach
TR7 applies IP reputation by merging lists from different sources in a single engine governed by category-based classification and exception control.
Hybrid feed model consolidates diverse sources
The TR7 central feed, external URL sources and user-defined lists converge in the same reputation pipeline. This structure prevents the organisation from being locked into a single closed list or a single provider.
Category-based classification makes the attack type visible
23 AbuseIPDB-compatible categories are supported — including DDoS, brute force, SQL injection, phishing, port scan, SSH and web application attack. Security policy can therefore be designed around attack class rather than just "bad IP". Counting the organisation's own blacklist and external feeds as their own namespaces, the engine classifies across 25 categories in total.
Whitelist precedence controls false blocks
IP addresses added to the user whitelist override the blocklist decision. Misclassified business partners, internal users or critical integration traffic can be moved into the exception scope quickly.
Periodic updates and manual triggers work together
The central feed can be updated on daily, weekly or monthly cron schedules. The operations team can also initiate a manual update from the management interface at any time.
Capabilities
TR7 IP Reputation Feeds process diverse threat lists — from the central archive to custom URL sources — in a secure and auditable way.
TR7 central feed is pulled periodically as an encrypted archive
The TR7 central IP reputation feed is received as an encrypted archive and updated according to the configured period. Daily, weekly and monthly cron schedules are supported. The update model uses a full-archive pull approach, so the local installation receives the current list in a controlled manner. In cluster deployments only the primary node pulls the central feed; other nodes are updated through synchronisation.
External URL sources carry the organisation's own threat intelligence
Users can define up to 10 external URLs. Each source is processed up to 50,000 IPs by default and the hard cap is 200,000 entries. These URLs can be internal SOC lists, industry sharing files or outputs from external threat-intelligence providers. TR7 adds these sources to the central decision pipeline, making the organisation's own security knowledge actionable.
21 network-type groups — three rules instead of thirty
Every source is classified into one of 21 network types — the major cloud providers, general hosting, CDN, verified bots, Tor exits, residential and mobile/CGNAT — and the same vocabulary is used by policy, DDoS thresholds, bot scoring and reporting. "Slow down datacenter traffic, challenge Tor, never touch mobile carriers" is three rules, not thirty address lists that someone has to keep current.
The twenty-one groups, and why these
Named clouds and hosting providers — AWS, Azure, Google Cloud, Oracle, Alibaba, Tencent, Huawei, OVH, Hetzner, DigitalOcean, Linode, Vultr, LeaseWeb, Scaleway, Contabo — plus general hosting for everything unnamed, CDN, verified bots, Tor exits, residential lines and mobile/CGNAT. The selection follows four questions rather than a vendor ranking. Where does automation actually come from? Nobody's browser runs in a datacenter, so the large providers are named one by one — a rule that says "Hetzner" is readable a year later; a rule that says "an address list" is not. What catches the rest? General hosting, so the long tail does not fall through. Where would blocking hit the wrong people? CDN, residential and mobile/CGNAT: behind one such address there can be a whole neighbourhood or thousands of subscribers, and an IP-level block punishes all of them for one. And where is the right answer a policy decision rather than a threat verdict? Tor exits — deliberate anonymity, which some organisations must allow and others must not — and verified bots, which must never be treated as malicious automation if you intend to stay in search results.
Custom HTTP header support enables authenticated feed retrieval
External feed URLs may require API keys, tokens or custom headers. TR7 supports adding user-defined HTTP headers per source. This allows open-text, intranet or authenticated list sources to be fetched with the same model. Organisations can consume security feeds without building separate integrations.
IPv4, IPv6 and CIDR entries are parsed automatically
Feed files may contain single IP addresses or CIDR blocks. TR7 parses IPv4 and IPv6 entries and maps them to the relevant category maps. Lines starting with # or // are treated as comments. This flexibility allows organisation and community lists produced in different formats to be used with minimal manual editing.
23 AbuseIPDB-compatible categories simplify policy scope
TR7 supports categories including DNS compromise, fraud orders, DDoS attack, phishing, open proxy, port scan, hacking, SQL injection, brute force, bad web bot, exploited host, web app attack, SSH and IoT targeted. Categories operate on binary classification logic — no weighted scoring or TTL claims are used. This clear model makes it straightforward to see which attack class is active and which source it comes from.
User blacklist and whitelist files are tracked live
Organisations can manage their own blacklist and whitelist files at separate file paths. File changes are tracked by a watcher mechanism and processed with a short debounce interval. When a whitelist entry exists, it suppresses the final blocklist decision. This structure accelerates urgent exception additions and the process of placing internal IP ranges on the safe list.
A single flat-list output can be consumed by other infrastructure
TR7 can also produce the processed blocklist information as a plain-text dump. This output provides a simple format that can be consumed by network security components or other infrastructure layers. Category maps can additionally be written to separate files. IP reputation therefore does not stay confined to the WAAP interface — it can be carried to different points in the operational infrastructure.
Size, timeout and abort controls govern the update process
Timeout and maximum size limits apply to external source retrievals. A 200 MB cap for the central archive, and duration and entry limits for external sources, keep the update process under control. Per-source progress can be monitored in the management interface and the operation can be cancelled if needed. These controls prevent faulty or excessively large feeds from stressing the system.
Operational depth
IP reputation operations become reliable through whitelist precedence, cluster synchronisation, file outputs and error control — not just through feed updates.
In-memory maps
TR7 maintains category maps, user blacklist maps, whitelist maps and external source maps as separate structures. External sources are traceable per URL. This separation makes it operationally clearer which IP intelligence comes from which source.
Whitelist decision precedence
IP addresses found in the whitelist are removed from the final blocklist output. In the application logic, such an entry is marked with a negative value and is not forwarded to the blocking pipeline. This behaviour ensures that business-continuity-critical exceptions are centrally protected.
File output locations
Category maps and flat-list outputs are written to specific file locations. Category-based JSON maps and list files are available for monitoring and integration purposes. This structure helps IP reputation data to be used not just in the management interface but also in file-based operational workflows.
Cluster synchronisation flow
When clustering is enabled, the primary node performs the central update. Secondary nodes receive the current data through synchronisation. This approach prevents each node from pulling the same feed independently and ensures consistent list usage across the cluster.
Per-source abort
A user abort flow can be triggered during an external source retrieval. On abort, the relevant response stream is terminated and the source update is halted. This control gives the operations team a safe exit for large, faulty or unresponsive feed sources.
Comment and CIDR parsing
Comment lines in feed files can be skipped without processing. CIDR-format blocks are accepted alongside individual IP addresses. This allows files produced by different SOC tools or sharing lists to be used more naturally.
When to use it
Bank consolidates SSH brute-force sources
A bank can activate the SSH category while also adding an internal feed URL produced by its own SOC. TR7 evaluates the central feed and the custom SOC list in the same reputation engine, moving brute-force sources to the blocking pipeline faster.
Telco applies category-based protection for DDoS readiness
A telecoms operator can open the DDoS attack, ping of death and port scan categories to classify risky sources before an attack begins. List outputs can be fed to network security layers so that drop decisions are made faster when an attack occurs.
E-commerce separates proxy risk in the fraud flow
An e-commerce platform can use the fraud orders, VPN IP and open proxy categories in the payment flow. Instead of a direct block, risky IP sources can be subjected to additional verification or tighter controls, balancing lost sales against fraud risk.
Closed network uses intranet feed
Public-sector organisations with restricted internet access can disable the central feed and use only a private blocklist URL on their intranet. TR7 pulls this list locally and processes it with category and whitelist controls, providing IP reputation enforcement even in offline architectures.
Frequently asked questions
How is the TR7 central feed updated?
How many external feed URLs can be added, and what is the entry limit?
How does whitelist precedence work?
How are the 23 AbuseIPDB categories used?
How are feed sources that require custom HTTP headers added?
Can IP reputation data be used outside the WAAP?
Combine IP reputation with your own threat intelligence
Central feed, external URL sources and organisational lists in a single reputation engine. Let's walk through a live setup in your own environment.