BRUTE FORCE PORT WINDOWS
After a little research, I determined SQL Server had the needed functionality to scan the event logs and run netsh to create Windows firewall rules. I knew of scripts written in PowerShell that scan the event logs for failed RDP connections and block IPs in Windows Firewall.
I removed the port forward in my firewall and resolved to allow access only over my VPN connection, but started thinking about other ways to harden SQL Server in the event that external access via port forward was the only option for a developer or system admin. Several thousand application log entries for SQL Server it was thousands of failed login attempts from a handful of IP addresses! I blocked them in my firewall, but soon more failed attempts showed from other IP addresses. One day, I was looking through the Windows event logs on the server while troubleshooting another problem and I noticed this: Though the database is not used for production purposes, I liked to keep it open to the internet for my own testing and application development. I first noticed the problem of brute-force login attempts on a SQL Server database I run on my home network. With some additional processing code, we can incorporate configurations for number of failed attempts to detect before blocking the offending client IP address and for clearing out blocked entries after a certain amount of time. The event log can be read to extract failed login attempts and obtain the remote client IP address and xp_cmdshell can be used to call netsh advfirewall to automatically add block rules in Windows firewall.
SQL Server has the ability to both read the event logs in T-SQL using sp_readerrorlog and execute command shell commands using the xp_cmdshell. We can detect and automatically block clients attempting to brute-force our database login using T-SQL on any version of SQL version 2005+. Even if the sa account is disabled and the attacker has to guess a login, these failed login attempts can unnecessarily waste resources on the targeted server.
Even then, this gives an attacker ample time to try tens of thousands of login attempts. The best that can be done is a periodic review of the SQL Server event logs and manually entering the offending IP address to Windows firewall or the edge firewall of the network. The worst is when the sa account is enabled and allowed remote access to the server if a legacy application employs this kind of database access, a system admin will be in a bind trying to maintain security of the server as an attacker can freely attempt as many login attempts as they want to guess the password. External access in combination with SQL Server login account access can make a database particularly vulnerable to brute-force attacks since SQL Server has no built-in functionality to detect consecutive failed logins and subsequently disable the account or block the offending client. Perhaps a mobile application connects to the database, making it infeasible or impossible to constrain access only to a set list of IPs whitelisted in the network or server firewall.
BRUTE FORCE PORT CODE
However, sometimes, opening SQL Server up to the internet is unavoidable because of design specifications of an application or legacy code that can't be modified. This is due to the wide availability of automated port scanners that scour the internet for open SQL Server ports and attempt a brute force or dictionary attack, typically on the sa account. Most security experts and DBAs strongly recommend against opening up the port SQL Server listens on (default 1433) to the internet. Windows Active Directory logins can also be employed for access so that AD security can be utilized (e.g., account lockout after failed login attempts). When deploying a SQL Server database that will be accessible to clients over the internet, it is always best to employ a VPN for clients to connect to the database's LAN.
0 kommentar(er)
