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:
- In my first post, Staying Safe from the Coming Storm, I outlined how SQL Server Authentication comes with the MASSIVE down-side of not having ANY logic that will force a login to be locked-out after multiple, concurrent, failures to authenticate. As such, SQL Server Authentication has absolutely no safeguard or protection against brute-force attempts.
- In my second post, SQL Server Authentication on Internet Facing Servers, I outlined exactly how frequently one of my SQL Servers in my lab was attacked via brute-force attempts to log-in as SA once I opened the server up to the ‘interwebs’. On average the server was getting hit over 6 times a second with brute-force attempts.
In short:
- You should try to avoid using SQL Server Authentication wherever possible. It’s simply NOT as secure as trusted (or Windows) authentication.
- You should also try to avoid exposing your SQL Servers to the interwebz—and/or use a different port if possible. (A different port will NOT protect you, but will mitigate risk a bit by making your server MUCH less targeted.)
- If you can’t avoid either of these scenarios, then you need to make sure you’re using very strong (as in LONG) passwords or pass-phrases for your logins and you should keep an eye on your logs periodically.
Enter IPMuncher
IPMuncher is an ingenious tool.
It works by doing the following:
- Monitoring Windows Error Logs. (By default it looks for Errors related to common attack/exploit vectors—but you can configure it to watch for ANY error OR you can even set it up to watch for flat files dropped into a specific directory).
- Parses those errors apart as they happen, and grabs the IP address associated with the error/file.
- Compares those IP addresses and events against rules (called IPMuncher Watch Rules) that you set up to define what should happen.
- Triggers changes to your Windows Firewall when an IPMuncher Watch Rule’s conditions are met.
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.)
A Picture is Worth a Thousand Words
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.
Get a 40% discount on IPMuncher
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.
