I’ve blogged twice about a serious flaw with SQL Server security on Internet-facing (or accessible) SQL Servers running with SQL Server Authentication Enabled:
IPMuncher is an ingenious tool.
It works by doing the following:
So, in essence, if I’ve set up my SQL Server to (log or) audit failed logins to SQL Server (see the section titled "Turn on Failed Login Auditing"), and then set up an IPMuncher rule to block any IP address that, say, fails to authenticate after 3 tries in < 3 minutes, then IPMuncher will spin up a new Windows Firewall rule to do exactly that. (And note that I’ll get this error whether the login is using Windows Auth or SQL Auth—so you might want to temper your failure rates accordingly.)
To put all of this into perspective, here’s a picture of my SQL Server Logs from a few months ago—when I put my server out on the ‘interwebz’ (on port 1433) to test how regularly it would be hit:
Again, on average, this thing was getting hit about 6 times a second. (At some points nothing was going on—at other times full-blown dictionary attacks were being mounted at pretty ridiculous rates or intervals.)
With that as background, here’s a picture of the IPMuncher rule that I slightly tweaked from the rule that comes out of the box when you deploy IPMuncher on your system:
As you can see, my rule is set up to block (for 5 days) any IP address associated with a SQL Server 18456 error (defined in the Windows Log Properties tab) at the rate of 3 error messages (or login failures) within 3 minutes.
With that rule in place, here’s a screenshot of my server after letting it run for a few days on my server—after putting my server back out on the interwebz:
Right in the middle you can see 3 failed login attempts from the same IP address within the space of one second, and then everything stops.
And, here’s why—a new Windows Firewall rule (created by IPMuncher) to block the EXACT IP address in question:
And what’s great about this—other than the fact that it worked 100% as expected—is that I can tweak the rule in question so that it’s either less aggressive or even MORE aggressive than it is—depending upon what I need and what makes the most sense. That, and this totally makes it possible to overcome the fact that SQL Server Authentication doesn’t have lock-out capabilities—by simply blocking the offending IP addresses for a specified (or indefinite) amount of time.
In short, IPMuncher is a fantastic tool.
It offers simple functionality, great flexibility, and easy configurability—meaning that it can be used to tackle a large number of tasks across a wide variety of servers and workloads.
Moreover, when I mentioned to Dave that I was so excited about how IPMuncher worked to solve this particular problem that I was going to write a blog post about it, he offered to provide a discount code for any of my readers who were interested.
For 40% off.
Of course, this offer is limited to 30 days within the publication of this blog post. But if you’re interested in what IPMuncher can do for you, download a free trial and take it for a spin. It’s still a fairly ‘early’ release (i.e., effectively still in beta form), but Dave’s VERY responsive to customer requests and needs and is always looking for ways to improve his solutions. As such, if you find that IPMuncher is a fit, you can run out and grab a copy at 40% off using the Coupon Code “SQLServer40”—without the quotes.