Any Reason Not To Block Malicious IPs?

We were in review of SOC playbooks a co-worker noted on one of the steps "No need to block malicious IPs. The attacker will just get a different IP address and keep attacking". Beats me, as at all the previous SOCs I worked at we always blocked the bad reputation IPs to execute containment.

Ok, I wanted to be really, really, really objective about this so this is my casting the "?" ball out there. Based on security best practices any reason not to block 'em as he mentioned? I'm sure to get some good tips from the gurus, or maybe confirmation of what my mind is defaulting to. If you cite some best-practices or reference material you got this from that's a plus.

Find more posts tagged with

macbook

incident response

blocking

soc

Comments

yoba222

While I don't work in a SOC, I disagree with your coworker and you should block malicious IP addresses. Your coworker's mentality to me is, might as well just leave all the doors unlocked because the criminal is just going to break down the door anyways. The downside is potentially interrupting the business because of blocking a non-malicious IP address, but if it's blacklisted, it's unlikely you'll be interrupting the business.

UnixGuy

Autoblock the poor reputation IPs. The pros: reduces noise in the logs, reduces junk traffic that should be later blocked anyway; cons: none.

SteveLavoie

As @UnixGuy said... just to reduce the load on your log... it is worth the effort.

Also why give a chance to an attacker... make it harder and harder so they will find it easier to attack elsewhere

JDMurray

To block an Internet IP or not to block an Internet IP; that is a common consideration for a SOC analyst. Here are some things to ponder for answering that question:

Who owns the IP?

The "owner" of an IP is usually considered to be the organization that appears in the IP's WHOIS record and a contact for that org will be listed in the same record.
WHOIS information can be very out-of-date or misleading, and finding the actual point-of-contact that manages the device(s) behind that IP can be a very time-consuming and frustrating experience that will often lead to a dead end.
FOr example, the person listed in the WHOIS record may only be the engineer at the org who requested the IP from IANA and not the admin of the box to which the IP is actually provisioned. (Both of these humans left the org years ago and the WHOIS record was not updated.)

Who really manages the IP?

The "manger" (or admin) of an IP is usually considered to be the person listed in the IP's WHOIS record, such as that long-gone engineer.
The registered owner of the IP is not necessarily the same org that manages the box(ex) that uses the IP either.
For example, imagine an encrypted tunnel between Org A and Org B. Org A owns the IPs at both ends of the tunnel and allows Org B to assign one of these IP to Org B's gateway on Org B's side of the tunnel.
That IP is owned (i.e., registered with IANA) by Org A, but it is managed and used by Org B, who is therefore responsible for all packet activity originating from that IP.
This configuration is (usually) proprietary and no public documentation of this configuration exists--unless someone in either org leaves an S3 bucket open and the network design docs are exposed to the Internet. (It does happen.)

How many computers and humans are using that IP to access the Internet?

Thanks to proxies and NAT, there can be many computers and humans behind a single IP address on the public Internet.
Just one of those (dozens/hundreds/thousands of) computers might be infected with Malware that is beaconing to its C2 server, or is being used by some human who is playing with a bunch of Nmap scripts.
The activity from this one "bad apple" will make that proxy IP look malicious, but your blocking that IP will also block access by all of the (dozens/hundreds/thousands of) "good apples" behind that IP too.

What is the maximum capacity of our Internet gateway devices for holding DENY ACL rules?

There is a finite amount of space for ACL rules in a network gateway device (e.g., router, firewall, reverse proxy, etc).
Most cannot block 1K's or 10K's of IP addresses because of RAM capacity and CPU processing limitations that will cause performance problems for the device if it were so provisioned.
However, some modern gateway devices have blocking capability that is separate from the normal rule set that can handle applying rules to many thousands of source IPs. (Does our org use one of those?)
Ask your gateway vendor if their appliance can be factory-provisioned to block all 7000+ ToR exit node IPs and automatically update itself as this list changes--every four hours. (Yeah, I didn't think so...)

What does (and doesn't) the latest OSINT threat intelligence say about the IP?

Threat Intel will tell you if the IP has been the source of bad activity, but it won't necessarily tell you when the bad activity occurred or why (and "if") the IP is still "bad."
You can skip the OSINT and just block the IPs owned by entire countries that are known for badness, but you may run into those gateway capacity and performance problems again.
Good Threat Intel is expensive because it contains original research and not just mostly regurgitated OSINT.

What's the worse that could happen if I block the IP anyway?

If the IP is owned by a customer or business partner (actual or potential), you will be blocking their ability to do business with your organization.
How will that make the leaders in your organization react when they find out from an angry customer or partner or other external entity that this has happened?
Hint: Your leaders believe that "Security should enable business, not prevent business."

Here is a TL;DR executive summary:

Don't block the IP; just detect and block the badness

Blocking the source IPs of ingressing packets is so 1990's.
You never really know who owns or is controlling the machine(s) on the backside of a public IP address.
Malicious traffic might be from a friendly source that's been hacked or infected with Malware.
Over the ToR proxy network, a single computer can use thousands of IPs to reach your org. (Block this, sucka!)
Attacks that don't care about return traffic (e.g., DDoS) will just spoof random source IPs to get packets through gateway blocklists.
Most gateway appliances have limited resources for blocking by IP anyway, so you can't block all the bad ones.
OSINT about IP addresses is usually very thin on useful details and never updated (such as checking if and when an infect machine behind a "bad" IP address has been cleaned).
Consider that it's the packet's payload that's the best indicator of possible badness and not the packet's source IP.
The solution? Use security appliances (e.g., WAF, load balancers, etc.) further along the packet's path inside your org's network to check packet payloads for badness and drop when detected.
Leave true packet filtering by source IP to your anti-DDoS service. (You have one of those, yes?)

UnixGuy

I should've probably elaborated more. Ignore my comment, what @JDMurray is a lot more accurate.

LonerVamp

To me, this all depends on what that IP is doing to me. I don't actually take into account that an attacker can just change their IP address. Most of the automated noise is not targeting me and will just move on. I don't mind temporarily blocking things, but it's usually low value. If it's a real attacker probing me, if they stay on the outside, I care very little if they rattle my doors and windows.

Also, if something gets coded as "bad" and it's really some content provider like AWS or DigitalOcean or RackSpace, there's a chance that any automated block is going to shun lots of legitimate and maybe even business-use sites.

I'm a believer in geoblocking if: a) you know you do 0 business with country/region X, and b) the feature is easily managed within whatever control you're looking at. Maintaining and updating a huge firewall rule with individual IP ranges is a hard no for me. Turning the feature on and clicking a box that says block Russia? Yes. Typically, knowing you do no business somewhere requires committee or approval of some sort, so I'd always start small and block the top 10 and any regulated regions.

I'm sympathetic to managing blocking dynamically using threat intel feeds, but I also understand you either manage the plumbing yourself, or you pay for the service. I'm not a huge believer in paying for this yet, at least for my organization. For most, though, I'd say if your DNS filter or web filter or other controls will have some level of automated blocked based on known bad IP, that can be an OK place to turn on.

Otherwise, I am not a huge believer in chasing down IP addresses to manage a block list. It's a lot of busywork and churn with some downside when denying business traffic and very little upside if that IP address isn't penetrating your defenses anyway.

egrizzly

JDMurray said:

To block an Internet IP or not to block an Internet IP; that is a common consideration for a SOC analyst. Here are some things to ponder for answering that question:
.
.
.
.

JD this is awesomely insightful, detailed, and very objective as to why "malicious" IPs should not be blocked. You certainly took the time to flesh out all the whys and whats. Mucho kudos brotha.

egrizzly

LonerVamp said:

To me, this all depends on what that IP is doing to me. I don't actually take into account that an attacker can just change their IP address.
.
.
.
.

Very awesomely crafted point of view as well @LonerV@LonerVamp . Key takeaways (1.) No issue turning on blocks for known-bad IPs and (2.) To block/not block depends on what the IP is soing.

JDMurray

All of that from me is from personal experience over the years. It's best to block by behavior rather than by IP, but orgs haven't had the technology to do that well prior to the past five years or so.

SteveLavoie

UnixGuy said:

I should've probably elaborated more. Ignore my comment, what @JDMurray is a lot more accurate.

@Unixguy Your answer is nice. @JDMurray just shoot this thread with a Bazooka of information

It is awesome some people that so much time to answer with that much detail their point of view, and it is one reason why Techexam community is great.

LonerVamp

I will say there can be issues doing blocks by IP. For instance, I don't want a firewall rule with a group or source list that is 1000 items long.

For some platforms, that is limited. For instance with AWS, your NACLs and SGs have pretty low size limits. So, you have to sort of do other things or not make that a hard dogma to follow.