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.
TR7 applies IP reputation by merging lists from different sources in a single engine governed by category-based classification and exception control.
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.
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".
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.
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.
TR7 IP Reputation Feeds process diverse threat lists — from the central archive to custom URL sources — in a secure and auditable way.
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.
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.
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.
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.
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.
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.
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.
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.
IP reputation operations become reliable through whitelist precedence, cluster synchronisation, file outputs and error control — not just through feed updates.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Central feed, external URL sources and organisational lists in a single reputation engine. Let's walk through a live setup in your own environment.