IP blocked by IP reputation & IP reputation mechanics

Last modified on 23 Aug, 2022. Revision 10

Question: An important webpage cannot be reached, the log in the Firewall says that the IP has been classified as Botnet and blocked.


It is very common in today’s world of virtual systems and lack of available IPv4 addresses to place multiple customers/systems/web pages etc. behind the same public IP and then separate that using e.g. an URL or DNS/FQDN. So depending on which URL we connect to we will end up on different web pages or virtual machines but still connect to the same public IP address. See below picture for an example.

IP reputation in cOS Core works by looking at the IP address and not the URL or DNS/FQDN. Meaning that if we take the above picture example and the IP gets blacklisted in the Firewall, all servers, virtual machines, web pages etc. behind that IP will get blocked by the Firewall. The main problem is to know what in this scenario is good and what is bad. It may be that VM-1 is infected with a trojan and joined a Botnet while all other systems are perfectly fine. But since the Firewall is looking at the IP it cannot make that distinction and all communication to/from this IP would be blocked until such time that the score of the IP address in question gets better or if the Firewall administrator decides to implement a whitelist of the IP.

But whitelisting the IP also comes with risks. What if the infected machine infects the users behind the Firewall as well? There is no direct answer to this question as it will be up to the administrator to decide which security policy’s to implement.

Question: An IP belonging to a known Cloud service (such as Office 365) was added to blacklist and automatically blocked, why?


This is basically the same problem as described above. An IP may have a low score but the underlying webpage on it is trusted as another server behind the same public IP is doing something bad. Manual checks of popular/common systems are not possible due to the millions of IP addresses which get blacklisted on a daily basis. IP addresses belonging to Microsoft, Google and Amazon (to give a few examples) can get blacklisted, since they are cloud providers in which any user can run services.

Unfortunately, this means that there is no obvious solution to this problem. Either the IP gets blocked and users are protected or the IP is allowed and users risk getting exposed to potential dangers. It will be up to the administrator to decide on the security policy and/or if the IP in question should be added to the Firewall whitelist.


One of the reasons for that is because Botnet blacklists both the source and destination IP address whenever it triggers. DoS and Scanner protection only blacklists the source IP as the main point of the Firewall is to protect the users from dangers on the Internet and not to protect the Internet from the administrators users. It is also quite unlikely that a scanner or DoS is initiated from behind the Firewall as reasonably the infrastructure behind the Firewall is protected by Anti-Virus programs and other security measures.

The Botnet protection blacklists both directions in case (for various reasons) a machine behind the Firewall gets infected and attempts to join a Botnet on the internet. We want to block the connection attempt even towards that IP address. We want to block the Botnet malware code on the infected network from talking to the controlling server. That is why we block outgoing traffic to IP addresses classified as Botnet, hence the reason why we blacklist both source and destination of the target IP by default.

Question: There seem to be more categories available for IP reputation such as Phishing, Proxy, Spam and more. Can they be used?


No, the only categories that can be used to take action are Dos, Botnet and Scanner as these are incoming traffic (except Botnet which is bi-directional) regardless of port used. The other categories are mostly used for outgoing traffic (except Spam Sources), as many IPs can host multiple sites blocking Phishing or Proxy will create unintended consequences and legitimate traffic would be blocked. These categories are meant to be used for forensic use in Clavister InCenter and/or InControl. If a user is communicating with for example an IP that is categorized as Phishing, the administrator can use these systems to verify what type of traffic triggered the event and if HTTP/HTTPS was used, which URL was used, to assess if the traffic is suspicious or not. If the traffic was really phishing the Web content Filtering (WCF) functionality can also block it.

Question: Can I configure my own IP reputation threshold values? I want to block things with a higher reputation score such as between 1-30 instead of current default of 1-20.


We have, in discussions with our vendor that provides the IP Reputation scores, found that 20 is a good level. If it was configurable, it would be difficult for the administrator to know what difference blocking at a score of 24 would have compared to blocking at score of e.g. 32. Only when an IP has lower score than 20, the classification is secure/confident enough to also set a category (eg “scanner”). Higher scores in the mid range (meaning between 21-70’ish) can also mean that the IP has been bad in the past and is slowly increases its trust score the longer it has not been observed behaving badly again.

Related articles

How to disable IP Reputation in cOS Core
21 Mar, 2023 core ipreputation log
CSPN (Clavister Service Provisioning Network) details for license & database updates
17 Nov, 2022 core license updates idp antivirus wcf ipreputation applicationcontrol
A trusted webpage blocked by IP reputation
7 Sep, 2023 core ipreputation
Protecting against the Apache Log4j exploit
15 Dec, 2021 core idp ipreputation log4j