- Audit on SQL Server (Server Audit)
- How to Create an Audit to Monitor Job Creation, Modification, and Deletion in SQL Server
- How to create an Audit trigger to log object manipulation in SQL Server
- SQL Server - How to implement audit and control of logins (Logon Trigger)
- Monitoring DDL and DCL Operations Using SQL Server fn_trace_gettable
- Using SQL Server Standard Trace to Audit Events (fn_trace_gettable)
- SQL Server - Permissions and privileges audit trigger at database and instance level (GRANT and REVOKE)
- SQL Server - How to Monitor and Audit Data Changes in Tables Using Change Data Capture (CDC)
- SQL Server 2016 - How to “Time Travel” Using the Temporal Tables Feature
- SQL Server - How to use auditing to map actual required permissions on a user
- SQL Server - Trigger to prevent and prevent changes to tables
- SQL Server - How to Create a Data Change History for Your Tables (Audit Logs)
- SQL Server - How to Avoid Brute Force Attacks on Your Database
- SQL Server Security Checklist - An SP with more than 70 security items to validate your database.
- SQL Server - How to know the date of a user's last login
- SQL Server - How to Avoid and Protect Against Ransomware Attacks Like WannaCry on Your Database Server
- SQL Server – Beware of server role securityadmin! Using privilege elevation to become sysadmin
- SQL Server - How to Avoid SQL Injection? Stop using Dynamic Query as EXEC (@Query). Now.
- SQL Server - Understanding the Risks of TRUSTWORTHY Property Enabled in a Database
- SQL Server - Password Policies, Password Expiration, Mandatory Password Change, and Login Lockout after N attempts
Hey guys!
In this article today I will demonstrate how brute force attacks occur on SQL Server and how to try to defend against such attacks.
What is brute force attack
Click to view this content.SQL Server brute force attack
Click to view this content.How to identify brute force attack in SQL Server
Click to view this content.How to monitor for possible brute force invasions
Click to view this content.How to Avoid Possible Brute Force Invasions
Click to view this content.Security in SQL Server - SERIOUS MATTER!
After demonstrating some ways to mitigate the brute force invasion problem by identifying and blocking the IP's that are trying to break into the Windows Firewall environment, we need to be serious about security. Unfortunately it is very common to see totally sloppy environments in the database security where application users have sysadmin permission, users who access the database as sysadmin, users with elevated privileges and weak passwords, xp_cmdshell and dynamic query being common practices in environments and many other very worrying scenarios.
Regarding the scenario of this post, which is the brute force attack, the vast majority of cases occur because the database is published to the Internet, making it very easy for potential attackers to enter and the possibility of someone trying to attack your instance. In many cases, this occurs when the bank server is the same as the application server, which is not a good practice for either the bank or the application.
The bank ends up disputing server resources (CPU, Memory, Disk, Network) with the application and has yet to be visible and exposed to the Internet, without the possibility of creating Whitelist (only the addresses in the list have access to the server), since This would prevent users from accessing the application. Not to mention that if the application server is long, database data can be accessed as well, which is a catastrophic scenario.
Another point that should be raised, too, is that even when the brute force attack is performed on the environment, even if it is unsuccessful it still manages to damage the company because as it keeps trying the thousands of passwords to break into the bank, This process ends up consuming a lot of server resources unnecessarily.
Also, lots of ransomware, with WannaCry (which devastated the internet last year) are usually preceded by brute force attacks to gain access to the database so that the attacker can take the databases offline so that Ransonware can then encrypt the data (mdf) and log (ldf) files.
What to do then to solve this?
Well, the FIRST step for this is to make the bank invisible to the Internet. If you have to separate the bank from the application and set up 1 server for each one, do it then, creating a VPN to make the communication between the 2 servers (if they are on different networks, like Azure). If the company is unable to afford a server for each one and the application is accessed over the Internet, through several IP's and there is no possibility of making a whitelist to limit the IP's that will access the server, the way is to implement the solution I made available above and hope that the worst doesn't happen, since the script in this article will block only trying to access the bank, but there are N other types of attacks to access the server, such as RDP, SSH attacks, etc.
The second step is disable and rename user SA and any other standard SQL Server users, as these users are the main targets for brute force attacks, since the attacker already knows the login and only needs the password.
The third step is to avoid using SQL Server authentication logins as much as the bank that has to control and manage these passwords. In addition, the hash of these passwords is stored in the database and can be easily broken and validated without generating any exception in the SQL Server log, as I demonstrated in the article. SQL Server - How to identify fragile passwords, empty or equal to username. Use Windows AD authentication wherever possible, eliminating the need to enter passwords, and SQL Server has no hash or password information.
The FOURTH step is to implement the monitoring of this article and always keep an eye on this report, blocking in the Windows (or Azure) Firewall the IP's that have many connection failures. This work must be CONSTANT and not just in a timely manner. He left the database available for internet, so now he can handle it. If possible, use this list of IP's to block these addresses at the organization level, in the general firewall of the network and not just in the bank server. You can also take lists of Range of IPs by Country and try to release only the IPs of Brazil (most comprehensive Whitelist).
Step FIVE is to periodically review the password for SQL Server logins in your environment. It is very important that these users passwords be changed at least 1X PER YEAR. Also, these users' passwords must be large and complex (I always use passwords with 50 characters or more, letters, numbers, and symbols). In addition, it is important to have an annual (at least) access review policy. sysadmin is for DBA only and db_owner should not even be used (save very rare exceptions).
Well guys, that was the article about Brute Force Attack on SQL Server. I hope you enjoyed this Security line, which is an area that I should invest a lot of time studying and writing articles this year and it is the theme of my talk on MVPConf Latam 2019.
A big hug and see you in the next post.
VERY COOL!
I was always worried about that.