Many attackers and hosts infected with malware try to infect other hosts by scanning networks for open ports exposed to the Internet. After finding an open port, a malicious third party will attack software running on that port using known vulnerabilities. These published software flaws can cause damage or allow unauthorized access to hosts and networks. Often vendors publish information about software flaws and offer patches directly to customers. Third parties also track and publish information about common vulnerabilities on web sites like https://cve.mitre.org and https://nvd.nist.gov/.
Although there are some new and sophisticated attacks, many breaches involve vulnerabilities that security professionals and vendors notified the public about years prior to the attack. For example, in the case of WannaCry, the malware used SMB vulnerabilities accessed via port 445. A SANS Internet Storm Center article dating back to October 2009 tells readers they should already know that port 445 needs to be blocked on the firewall.
In some cases, patching all the hosts in a network to fix vulnerable software is not feasible due to the number of hosts, or even possibly due to systems that require outdated software. Knowledge of the ports needed for common vulnerability exploits to work is useful because it allows network administrators to block problematic ports. Even if software is unpatched, the malware will be unable to function correctly if it cannot communicate on required ports.
The WatchGuard Firebox has a feature which allows administrators to easily block a network port. In the WatchGuard Firebox Admin Web Site, click on “Firewall” on the left menu, then “Blocked Ports” to see the list of blocked ports.
Use the buttons at the bottom of the page to add new ports:
The auto-block feature allows administrators to automatically reject connections from hosts generating suspicious traffic. Check the box at the top of the list to auto-block any host that tries to connect to a disallowed port. The Firebox adds the host to the “Blocked Sites” list and rejects any future attempts by the blocked host to connect on any port.
For example, if a network administrator has blocked ports 445, 137, 138, 139 and 23 and a host tries to connect to those blocked ports, there’s a good chance that traffic is coming from an attacker server, an infected or misconfigured host. With the auto-block feature, the WatchGuard Firebox will automatically add that host to the “Blocked Sites” list and block any further connection attempts from that host. Note that this feature will disallow the port on the entire network so make sure it is not required internally or externally by hosts served by that firewall.
With these features enabled, network administers can periodically review the list of hosts that the Firebox automatically blocked by clicking on “System Status” in the left menu and then “Blocked Sites.” This list will tell the administrator which hosts tried to connect on blocked ports. An auto-blocked host will show up with the reason “blocked port.” This information may be useful in creating new firewall rules or troubleshooting network problems.
Auto-blocking rogue hosts not only helps protect the network, it may improve the performance of the firewall as well. If the firewall is completely blocking all traffic from a host, it will not have to perform further inspection on any traffic from that host. The firewall can immediately drop the traffic. This saves processing power and hopefully improves performance for valid hosts on the network. — Teri Radichel (@teriradichel)
Is this only active on incoming connections from the untrusted interface or will it block hosts internal to the network who try and connect outbound too?
Autoblocking will work both ways, and can apply to internal too. If you are purposely egress filtering, you shouldn’t turn autoblocking on for those ports as it could affect internet devices too (or so support tells me).
Thanks, It would be really useful to be able to lock this to the untrusted interface so we can allow outbound from trusted and internal to DMZ connections without people getting blocked. As an untrusted inbound defense this would be really useful as you can see the same IP’s slowly scanning through ports continuously.
One customer wrote to me and says she successfully uses the auto-blocking feature to protect against DDOS attacks but yes, it must be implemented correctly. Auto-blocking can also be applied to individual rules. More info in this post: Using Firewall Policies to Auto-Block Rogue Hosts on External Networks
That actually works quite well. I didn’t notice there was an auto-block per rule option (which release did that appear in?)
Just added an autoblock on any external IP trying to connect over SMB and my block list has gone from about ten to a few hundred.
I create firewall polices for telnet, SMB/CIFS, LDAP and various other ports with an action of auto block. By making them firewall policies, I can control that they only apply to “external” traffic.
I have a feature request lodged with Watchguard for an API to register an IP that should be blocked, for example if a web app we have written running on a server in trusted detects a brute force, it would be great to trigger a ban at the edge (like Fail2Ban). Let’s hope this gets implemented.