Smarter by Design.Simpler for Business
IP Reputation Protection
What Is IP Reputation Protection?
IP Reputation Protection is the protection layer that evaluates the request by looking at the history of the source address. The volume or the behavior of the traffic is not decisive: if the address is recorded in a category in the threat intelligence database, the action defined for that category is applied. There is no counter, time window or threshold; the decision is based on a single lookup result.
The database that the protection looks at is not kept on this screen: the address lists are managed across the device, from the IP Intelligence & Reputation screen. This card only defines what will be done with the categories in that database.
The protection is not a threshold list but a rule list. Every rule row in the list covers one or more categories and says what will be done with the addresses recorded in those categories. The rows are read from top to bottom and the first row that matches gives the decision.
25
Reputation Categories
23 threat categories together with the operator's own blacklist and external sources
Active
Default Mode
The only exception among the three protections: this protection applies enforcement from the first moment
First Match
Evaluation Model
Not the hardest action but the row that matches highest in the list wins
7
Action Options
Silent Drop · Block · Tarpit · Redirect · Show Content · Show Captcha · Quarantine
2 Rows
Default Rule
The attacker categories are taken into quarantine and the rest are blocked with 403
Local
The Reputation Lookup
The query is made in the device's own category files; no request is sent to an external service
Two Layers
Exemption
The device-wide whitelist does not list the address at all, and the vService whitelist bypasses the rules
In Every Type
HTTP and L7 TCP
On L7 TCP vServices the action set is limited to Silent Drop and Quarantine
Active
The rules are applied
It is the default mode. The source address is looked up against the categories and the action of the row that matches is applied.
Monitor
It looks up, it does not intervene
The classification works as it is: the category distribution is counted and the "what would have been done" stamp is put into the event log, but no request is stopped.
Off
The protection does not work
The rules are not evaluated at all and the category distribution is not collected either. The card fades; the Edit link, on the other hand, stays active, because it is the way of turning the protection on again.
Why is the default of this protection Active?
The other two protections (L7 DDoS Protection and Bot Protection) open in the Monitor mode by default; because both of them work over thresholds and behavior and can produce false positives. IP Reputation Protection, on the other hand, is list-based: the decision is based on the address matching a known record exactly. For this reason its default is Active and the protection applies enforcement from the first moment. Turning it off or taking it into monitoring is a conscious decision of the operator; the Off value is therefore counted as "turned off manually" and the learning engine does not turn it on by itself.
The IP Reputation Protection Card on Bot/DDoS Management
The card is the second of the protection cards on the Bot/DDoS Management screen: it is located between L7 DDoS Protection and Bot Protection. In its title the name and the definition of the protection, at its top right the verified bot trust, the exemption information and the mode badge, and in its body the Action Rules box are located.
Bot/DDoS Management - The IP Reputation Protection Card
The anatomy of the card:
| Section | What it shows |
|---|---|
| The title | The name of the protection and its one-line definition: What is done with a source IP according to its reputation record and category |
| Trust Verified Bots | Whether verified crawler bots are exempted from the protection: Enabled or Disabled. |
| Whitelist | The condition that defines the traffic to be exempted from the protection. If it is not defined, — is written. |
| Whitelist Rules | The number of rows defined in the shortcut list next to the condition. If it is empty, — is written. |
| The mode badge | The own mode of the protection: Active, Monitor or Off. The Edit link below the badge opens all the settings of the protection. |
| Action Rules | The list of the category-based action rules. The number in parentheses next to the title is the number of the rows whose action is defined; every row is turned into its own sentence. |
The Action Rules box does not have its own pencil
In the other protections every box in the body is opened with its own pencil icon. Here, since the rule list is also kept in the same schema group as the other settings of the protection, there is a single edit window: the Edit link at the top right of the card opens the mode, the exemption and the rules together.
How Is Action Rules Read?
Every rule row in the list is reduced to a single sentence. The sentence consists of two parts: in which categories the addresses covered are and what will be done.
traffic from Category
<categories>:<action>
| Part | How it is written |
|---|---|
| The categories | All the categories selected in the row are written one by one, with their interface names and separated by commas. There is no +N folding as in the country and network type rules: the row uses the whole width of the card. |
| The action | The verb of the action is written and, if it has a parameter, it is added: the status code in blocking and in showing content, and the redirection code in redirection. The redirection address does not enter the sentence at all; to see the address, the rule must be opened on the Edit screen. |
| The color | Silent dropping, blocking, tarpit and quarantine are written in red; the challenge, the redirection and showing content in amber. |
A row whose category has not been selected loses its sentence and appears only with its action, in the form → block 403. If no rule is defined, a single row remains in the box: Categories: —.
A row without a category is counted on the card but does not work
The number in parentheses counts the rows whose action is defined; the ones whose category is empty are also included in this number. On the other hand a row without a category is not applied to the traffic at all: it continues to stay in the record, but it is not written to the working configuration. While "Action Rules (2)" is written on the card, it is possible that a single row is really working.
Categories
The category list comes from the product's own fixed category definition and consists of 25 entries; the threat intelligence database managed from the IP Intelligence & Reputation screen fills the content of these categories. The entries are as follows: 23 threat categories, the operator's own blacklist (User Blacklist) and the external feed sources that the operator defines (External). The technical working of all three is the same; their difference is where the data comes from.
The table below gives the categories in the order of the drop-down list in the interface and together with their place in the default rules.
| Category | Its place in the default rules |
|---|---|
| DNS Compromise | Block 403 |
| DNS Poisoning | Block 403 |
| Fraud Orders | Block 403 |
| DDoS Attack | Quarantine |
| FTP Brute-Force | Block 403 |
| Ping of Death | Block 403 |
| Phishing | Block 403 |
| Fraud VoIP | Block 403 |
| Open Proxy | Quarantine |
| Web Spam | Block 403 |
| Email Spam | Block 403 |
| Blog Spam | Block 403 |
| VPN IP | It is not located in the rules |
| Port Scan | Block 403 |
| Hacking | Quarantine |
| SQL Injection | Quarantine |
| Spoofing | Block 403 |
| Brute-Force | Quarantine |
| Bad Web Bot | Quarantine |
| Exploited Host | Quarantine |
| Web App Attack | Quarantine |
| SSH | Block 403 |
| IoT Targeted | Block 403 |
| User Blacklist | Quarantine |
| External | Block 403 |
Why is VPN IP not in the default?
The VPN IP category is in a selectable state in the list but it has not been put into any of the default rules. The reason is the density of legitimate use: a significant part of the corporate and individual users connects to the service over a VPN. Adding the category to a row has been left to the decision of the operator.
Where does the data of the categories come from?
This screen defines what will be done with the categories; it does not manage the content of the categories. The address lists are managed from the IP Intelligence & Reputation screen: the update period, the external feed sources and the content of the operator's own blacklist/whitelist are there. The whitelist on the same screen works at a layer below this protection: an address written into the whitelist is not written to any category file, and therefore the rules never see it.
The Default Rules
On a new vService the protection does not start without rules. When the protection is enabled, a two-row default configuration is written to the configuration record created, and these two rows are applied to the traffic.
| Order | The categories it covers | Action |
|---|---|---|
| 1 | DDoS Attack, Open Proxy, Hacking, SQL Injection, Brute-Force, Web App Attack, Exploited Host, Bad Web Bot, User Blacklist | Quarantine |
| 2 | All the remaining categories (except VPN IP) | Block, status code 403 |
The second row is not counted manually, it is derived from the remaining categories: when a new category is added to the product, the default definition covers it as well. A rule list that has already been saved, on the other hand, does not grow by itself. VPN IP is kept outside both rows.
On L7 TCP vServices the twin of the same list is written: the quarantine row stays as it is, the blocking row turns into Silent Drop and the status code field drops.
Emptying the list does not turn the protection off
When the rule list is left empty, the protection does not work without rules: the default two rows come into play again and the enforcement continues to be applied. In this case, even if the card writes Categories: —, the default rules are applied to the traffic. The only way of really stopping the protection is to make the mode Off. This has a cost: when the mode is made Off and saved, the exemption definition and the rule list are also deleted from the record, and when the protection is made Active again, the default two rows come into play.
The Row Order and the Priority Between the Layers
The rule list works with the first match wins model: the rows are tried from top to bottom, the action of the first row that matches is applied and the rows below are not tried. If an address is recorded in more than one category, the row higher in the list gives the decision; the hardness of the actions is not looked at. For this reason the row order is not a display preference but the priority itself.
The own decision of the protection is also subject to the order between the three protections. The evaluation order is in the form L7 DDoS Protection → IP Reputation Protection → Bot Protection: first the volume is cut, then the known bad addresses are sifted out, and last the behavioral bot evaluation is made. If L7 DDoS Protection has applied an enforcement on the same request, the action of IP Reputation Protection is not fired; on the other hand the own counters and the category distribution of the protection still work.
The shared quarantine box is ahead of this order as well: for a source address that is already in the box, none of the three protections is evaluated, and the box gives the decision directly.
The quarantine and the challenge are managed from the shared cards
The Quarantine and Show Captcha actions do not carry any additional field in the rule row. The penalty period, the tracking window and the challenge settings are defined on the Quarantine and Captcha cards and are used in common by the three protections.
Edit
The Edit link below the mode badge of the card opens all the settings of the protection: the working mode, the exemption defined in two forms and the action rules themselves.
| Setting | What it does |
|---|---|
| IP Reputation Protection | Determines the mode of the protection: Active, Monitor or Off. Its default value is Active. |
| Trust Verified Bots | Exempts verified crawler bots from the rule list. It is on by default. |
| IP Reputation Whitelist Condition | Defines the traffic to be exempted from the protection with a condition. |
| IP Reputation Whitelist Entries | The shortcut list of the same exemption written row by row; the rows are in an "or" relationship with each other. |
| IP Reputation Actions | The category-based action rules. In every row the categories covered, the action to be applied and the sub-fields bound to the action are located. |
Details: Edit.
Scope and Limits
INFO
- It is present on both vService types. On L7 TCP vServices the selectable actions are limited to Silent Drop and Quarantine; the actions specific to HTTP are not located in the list.
- The default mode is Active. The protection applies enforcement without the operator doing anything. The default of the other two protections is Monitor.
- The decision is based on a single lookup. There is no threshold, counter or time window; if the address is recorded, the row matches.
- The first matching row wins. The hardness of the actions is not compared; the ordering is the decision itself.
- The rule list can be emptied, but the protection does not work without rules. In the edit window the last row cannot be deleted; in the record the list can still stay empty. In that case the card shows
Categories: —and the default two rows are applied to the traffic. - A row without a category does not work. It is counted and shown on the card and it stays in the record as well; however it is not written to the working configuration.
- The exemption is at two separate layers. The device-wide whitelist on the IP Intelligence & Reputation screen does not list the address at all; the vService whitelist, on the other hand, prevents a listed address from entering the rules.
- The exempt traffic is still written to the event log. The requests that have been listed but on which no enforcement has been applied continue to produce records; the records are suppressed per actor and the row itself writes which event number it is.
- The source address is subject to the real client IP definition. If a client address override such as
X-Forwarded-Foris active, the reputation lookup is made over the overridden address. - The category distribution counts only the categories that appear in the rules. For an address recorded in a category that no rule covers, the distribution counter does not work.
- The classification works in the Monitor mode. The category distribution is collected and which action would be applied is written to the event log; the traffic is not touched.
- The Edit link depends on the permission. The card is displayed with read-only permission; the Edit link is displayed only on the users that have edit permission. While the protection is Off, the link stays in a clickable state as well.
