Problem description

We got feedback from some of our users that a webpage that they are trying to access is not working. When checking the Firewall logs we see that it is because the IP has been blacklisted by IP reputation.

Reason

The reason for this is because the IP address in question has a low IP reputation score and is part of a category that is watched for by the Firewall (such as Botnet, Scanner and DoS). If a IP has a score of 20 or lower, it will be automatically added to the Firewall’s blacklist and any connection to/from this IP will be blocked.

To manual check the IP reputation score of an IP the following CLI command can be used:

IPreputation -query <IP address>

The output could look something like this:

VSG-3:/> ipreputation -query 192.0.2.55
Result of query:
-------------------------------
Address : 192.0.2.55
Response IP : 192.0.2.55
Reputation : 6
Categories : Windows_Exploits BotNets Phishing Proxy
In IP Threat List : 1
Found in : Local Database

There are 3 types of database the IP reputation query response may come from:

• Cloud Lookup - The IP was found on an external database server.
• Local Database - The IP was found in the high risk part of the IP reputation database that is kept locally by cOS Core.
• Cache - The IP was found in the local cOS Core cache, meaning that either it had been already looked up recently or was contained in a partial database update (as previously explained, partial updates to the high risk local database are initially stored in the cache).

In the above example, the query found a matching IP in the Local high risk database. Which means that the score for this IP is deemed quite dangerous and any incoming/outgoing communication to this IP would be blocked.

Potential problem

A problem that can occur with IP reputation is when there is a host provider involved. The host provider will in many cases share the IP address with tens, hundreds maybe even thousands of other web pages. The provider distinguish the incoming traffic based on URL and not IP. But from cOS Core’s perspective we only look at the IP. So there may be 100 pages that are totally safe to use but one that contains malicious information, act as a Botnet or other bad things that cause the IP itself to  have a low score. The Firewall would then blacklist the IP anyway regardless if there are “good” pages behind the IP, see below image for an example.

Solution/workaround

There are three potential solutions/workarounds to the problem.

1. Investigate why the IP has low score, solve the problem (e.g. purge malicious content, perform virus scanning/cleanup etc).
2. Contact the service provider and ask to be placed on a different IP that has a better IP reputation scoring (and maybe not shared with many others).
3. Add a whitelist exception in the Firewall (see below).

If the administrator would like to allow access to the IP regardless of the potential risks, it is possible to whitelist the IP. In the WebUI this is done under “Threat Prevention→Whitelist”.

To perform a similar operation from the CLI, the CLI command is as follows (and yeah, the name of the command is not obvious ):

add BlacklistWhiteHost Address=192.0.2.55 Service=all_tcp

Note: The above syntax only whitelists the source address, not the destination and that may not be the intended purpose. If destination should be whitelisted, the CLI command for that is:

add BlacklistWhiteHost Address=192.0.2.55 Service=all_tcp TargetNetwork=Destination

The resulting output from the CLI would then look like this if both of the above commands are added + activated on the Firewall:

VSG-3:/> blacklist
Blacklist

        
Type Host Service, Proto/Port Destination Time to Live
---- ----------------------------- ------------------- ------------------ ----------------
dyn 192.0.2.55 All /All All 98

        
Whitelist:
Type Host Service, Proto/Port Target Network
---- ----------------------------- ------------------- --------------
sta 192.0.2.55 all_tcp Source
sta 192.0.2.55 all_tcp Destination

Note: Whitelisting of destination did not function as it should until cOS Core version 13.00.07 and up.

Related articles