Alerting based on IP reputation blacklists can have some value, but IP Blacklists are not a strong indicator of threats, despite what many claim. IP reputation blacklists are notorious for their low quality, which makes alerts based on them less reliable and requires more analysis to verify that something malicious is occurring.
Here are 5 Reasons Why IP Blacklists are unreliable:
- Malicious IP’s change frequently
- IP Blacklists are automatically generated
- Blacklists lack context
- Blacklisted IP’s are inaccurate
- Too many Blacklists exist
1. Malicious IP’s Change Frequently
If a blacklist is not kept updated daily or even weekly, the list will rapidly become inaccurate. Hackers tend to change IP infrastructure frequently due to IP’s being tagged as malicious and being blocked by security devices. At most, IP’s are reliable for about 30 days, but many think anything more than a week or two is too long to trust. Thus, blacklists tend to be full of IP’s that may have been used maliciously a while ago, but no longer are. This results in false positive alerting, which is also very common in IP Blacklist based alerting.
2. IP Blacklists are Automatically Generated
Most blacklists are auto generated based upon a set of conditions that suggest bad or malicious behavior is occurring. For example, an SSH Brute Force blacklist looks for inbound connections attempts over SSH. Typically, if multiple occur, the system adds the IP to a blacklist. Unfortunately, the context around the IP is not captured. An IP is added even if most of the activity from that IP is not inherently malicious. Additionally, the auto creation is not perfect and often activity that is not malicious is construed as such and added.
3. Blacklists Lack Context
Essentially, just because an IP is being used by one actor or domain for malicious activity doesn’t mean the IP itself is wholly dangerous. Consider IP addresses that host thousands of domains. If just one domain or one threat actor using a website hosted on that IP is doing malicious activity that IP will be blacklisted. This is very common and we see this frequently in the SOC.
4. Blacklisted IP’s are Inaccurate
Revisiting #2, things are frequently changing on the internet. Benign activity is often misconstrued as malicious and then gets added to black lists.
5. Too Many Blacklists Exist
In reality, there are thousands of blacklists out there and most are unreliable. It is difficult to sift through and determine the quality ones. Using more blacklists for threat detection is typically counterproductive because of these data quality issues. Fewer is better if those fewer are higher quality.
Unfortunately, many people don’t understand that just because an IP is blacklisted it doesn’t need to be notified every time. In fact, blacklisted IPs, in my opinion, should only be actionable if at least one of the following three conditions exist:
- It is from a blacklist that is specific to a known and active threat and the black list is frequently updated. (Usually these are premium lists that cost quite a bit to get)
- The IP is widely blacklisted on multiple lists and by multiple I mean at least 10-20.
- The blacklist alert is correlated with other alerting that suggests malicious activity is going on. In other words, the fact the IP is blacklisted is part of the story, not the whole story.
Let’s look at a couple of examples, here are a few trusted IP addresses, I ran them through a multi RBL tool (http://multirbl.valli.org/lookup/69.92.173.77.html). I chose this because it runs the IP through 240 blacklists:
IP Address | Description | # of Blacklists |
98.202.84.255 | The IP address of this computer | 17 |
104.196.246.48 | Securityondemand.com | 4 |
151.101.1.164 | Nytimes.com | 3 |
As evidenced by these few examples, innocuous IP’s show up on more than one blacklist. So simply being blacklisted is not a good or trustworthy indicator. As mentioned above, to make blacklists valuable there needs to be conditions around it.
For more information on the best threat indicators to use, feel free to chat with us here.