Automatically preventing all traffic from hosts that attempt to connect to blocked ports can help prevent further malicious actions from those IP addresses as explained in Auto-Blocking Suspicious Hosts Found in Traffic Logs. After posting that article, one WatchGuard customer sent me a note about using the auto-block feature to help prevent DDoS attacks. By reducing the processing time for known bad hosts as explained in the last post, the firewall has more resources left to handle other requests.
Some readers asked how to auto-block a port for external traffic only. For example, some environments need port 443 to be open on all or part of the network inside the company, but any attempt to connect to that port from an external source should be auto-blocked. In that case, instead of blocking every connection attempt on port 443 automatically, create a policy which denies external traffic on port 443 to the Firebox and Any-Trusted aliases. The “Any-Trusted” alias covers networks defined on, or routed behind the trusted (internal) interfaces. The “Firebox” alias covers any IP address assigned to the Firebox, public or private. Then check the box labeled “Auto-block sites that connect to attempt to connect.”
I suggested this in the comments of my last blog post and someone tried it out. As soon as he turned on the rule, the logs filled with hundreds of auto-blocked IP addresses.
If a valid host accidentally connects to a port in the policy above, the Firebox will add that host to the auto-block list along with all the malicious hosts. This may be a good thing because a presentation at Def Con talked about the potential threat from internal DDoS attacks. However, If a firewall administrator wants to ensure certain hosts that connect to a denied port are not completely blocked, create a separate deny rule with auto-block turned off for those IP addresses. Make sure the rule with auto-block off is above the rule with auto-block on in the policy list. — Teri Radichel (@teriradichel)
This looks like the perfect recipe for a self-fulfilling DOS attack. All I need to do is generate a ton of requests from spoofed legitimate sources and I can start blackholing revenue driving traffic. That could get ugly very quickly.
Yes good point – I mention that in the blog post in the last paragraph and how to prevent blocking valid IP addresses. Another comment mentions a different approach below. The WatchGuard Firebox will block spoofed IP addresses.
Auto-block per rule has been around for over 5 years. I use auto-block for RDP (3389), Proxy Relay (3128) and a few other ports that a hacker might try. The other nifty feature with a deny rule, is that you can choose the message you send back – ICMP Network Unreachable is a good one to use to fool the attacker that you might not even exist…
There is an exclusion list for favored IPs in the default protection tab. That works well. You can put single addresses or subnets in there.
Haha, nice!
Definitely a good option! However, please make sure you do not have SSLVPN with the default port enabled as this is on port 443 as well. Thought I should mention it as this example is set on 443.
Yes perhaps a better example was to block 445 as was mentioned in the related post which was the port required by WannaCry.
We found autoblocking 445 was problematic as corporate laptops which on campus had drives mapped would try and hit IP addresses of internal servers on 445 (which are blocked) and this would add them to the blocklist preventing access to valid web services.
Yeah, you do need to be somewhat careful with autoblocking. With great power comes great responsibility. It’s too bad though, port 445 (and the other Windows SMB/Netbios ports like 137-139) are good ones to block when you don’t want file sharing.
We do block them externally, but just can’t use autoblock as it blacklists valid users trying re-map their drives from home, even though they can’t…
Deny? Do you guys still use the default Outgoing policy? That thing needs to be deleted!
Just an update…..
I’ve been using autoblock now since august and there is one major issue with it, which is the 8,192 host limit (used to be 1024 I believe).
After reviewing the logs i’ve noticed that most IP’s hitting the couple of honeypot ports (i’ve got on the autoblock policy) are failing to add to the list due to capacity issues.
Reducing the time to 15 minutes from the default 30 may help, but for us it filled back up within 10 minutes and started throwing up the error
2017-12-08 16:28:46 Primary kernel [2506571.229649] xt_session: “hostiles” limit 8192 exceeded, cannot add entry for 219.115.212.168
Is there any way of raising the limit without too much of a performance impact?
That is interesting. I wasn’t aware of that limit myself. I will talk to product management. I don’t know if there is a resource or memory limitation, however, on our bigger boxes it should be theoretically possible to raise the limit. I will bring this up with them.
Thanks, This is a pair of M4600’s which have a fair amount of resources.
Hi, Just wondered if there were any plans to raise that 8k limit? thanks