February 1, 2005 at 11:13 am
My SQL server has been getting hit a lot lately with somebody trying to get the sa password. It is usually a host name of server, and thus far all attempts have failed. Any idea how to prevent this from happening? It does have a public IP address, and all the latest SQL and Windows patches and updates applied. I am running Windows 2000 server, SP4 and SQL server 2000, SP3a plus patches.
February 1, 2005 at 2:05 pm
How about shutdown all internet traffic to that server at the firewall. Also allow only the intranet traffic to talk to that server.
mom
February 1, 2005 at 2:47 pm
Who connects to SQL Server? Users or an application on this server? If it is only an application on the machine that connects to SQL Server then disable TCP/IP in SQL Server "Server Network Utility". You may as well disable Named Pipes leaving enabled only Shared Memory protocol.
Please, keep in ming, that everyone including yourself and other administrators will be able to connect to this SQL Server in this case ONLY LOCALLY. NOBODY will be able to connect directly to SQL Server over the network. On the other hand users who use applications on the server will connect to them and the app will login locally.
Disclamer: try it in the development first and we are not responsible for the outcome, try on your own risk.
Yelena
Regards,Yelena Varsha
February 1, 2005 at 3:08 pm
1.I hope you don't have access allowed directly to SQL Server from the internet. If you do cut it immediately
2. Follow mom suggestion. Firewalling traffic at least only from the DMZ if at all possible.
3. On the Firewall you could stop an specific IP from access but that is usually spoofed so you just get a temporary relief.
4. Make sure your password is strong enough.
* Noel
February 2, 2005 at 3:52 am
If you can do inclusive firewalling (limiting the access to a limited IP set), then do that.
It gets round the issue of having external addresses spoofed, or proxied through compromised machines.
Only those boxes you want authorised can directly access the SQL Server.
If you're running the box to drive something like a web page, then get the scripts to use a local access method.
If you need arbitrary numbers of users from random IP Addresses to use TCP/IP to connect over the net to your SQL server, you already have a problem.
If you honestly believe it's a compromise attempt (it looks like it), then the best solution is actually non-technical.
Log the address and attempts. Find the owner of the originating IP.
If it's part of a company (check in the whois info), get a contact inside the company in their IT department. Ask them why you're getting SA attempts from their machines.
If they're compromised, they can log access, and slowly trace backwards.
If it's from an ISP dialup, contact the ISP, and alert them that the machine is sending SA brute force crack attempts.
Ask them to monitor activity (so that if the dialup is in fact a zombie, pre-cracked for use in proxying further cracking attempts), the ISP can request the user fix their machine before using the internet service.
If the task originates locally (no proxying, so it's either a silly attempt to crack from their own box, or an automated crack script left on the zombie), then the ISP can investigate further.
February 2, 2005 at 6:31 am
Make sure you have security mode set to Windows only. Mixed mode authentication is inherently less secure.
Using Windows only authentication means no-one can connect using the sa account, even if they do know the password.
In our shop, we have a Windows group that holds all the accounts of each DBA. We have authorised this group as a SQL sysadmin, and removed BUILTIN/ADMINISTRATORS. We have had no problems with this, and Windows only authentication works just fine.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 2, 2005 at 7:05 am
There's a lot of good advice to your post. However, to tailor a recommendation for your situation, we need to know a bit more. Recapping some of the questions (and adding a few of my own):
- Does this SQL Server sit on the public Internet?
- Do you connect via a SQL Server login or a Windows account?
- Do you have the option of changing the default listening port?
- Are you always coming from a range of IP addresses (or better yet, a single IP) such that you can restrict what IPs are allowed to connect to your SQL Server?
- What firewall options do you have available to you?
K. Brian Kelley
@kbriankelley
February 7, 2005 at 10:23 am
The server has apublic IP and currently does not sit behind a firewall. We have no choice but to use mixed mode logins. Can't change the ports at this time or probably not in the future as Sql server drives or is driven (not sure which) by our website. Whave users from many various IP's connecting to the server to make changes, etc to Sql server. We are in the process of getting a firewall and putting the Sql server on a private network, but it could be another 2 weeks the way it looks. Where my Sql server and web servers are colocated, port 1434 is block by the ISP's firewall, but not 1433. Not sure how my network guy is planning on setting up the firewall. Hopefully, he is going to block all access except to certain IP's that need access. I am thankful that my sql logins have very hard passwords.
February 7, 2005 at 11:42 am
Given this situation, use a password generator to create a complex password for your sa account and use it. You're going to want a strong password. Because as of right now, given your constraints, you're not going to be able to prevent brute-force attacks against your SQL Server. Even with the firewall in place, still generate a long and complex password in order to protect yourself.
K. Brian Kelley
@kbriankelley
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply