We suffered a brute force attempt on our SQL database yesterday and obviously want to prevent this from happening again. The bot or whatever it was was trying to log into the sa account about 30 times a second so in the first instance we have changed the sa account and restricted the IP range that can access SQL via windows firewall. We are also considering disabling the sql server browser and changing the default port.
The problem is none of these things will prevent malicious log in attempts.
I came across a piece of open source software called QaasWall and wondered if anybody had used it and whether it is reputable.
Here is a link to the project site: http://sourceforge.net/projects/qaaswall-window/
Any other tips on how to restrict the number of server log in attempts would be greatly appreciated.
Many thanks.
Clayton.
The best solution is completely disabling access to the database from all hosts which do not need it. E.g. by binding to localhost if the DB is only accessed locally or blocking any connections to the IP/port used by the DB in your firewall.
TheifMaster is correct...the SQL Slammer was really vicious, but installing SQL Server SP3 or SP4 fixed the vulnerability in the sql server listner that this worm exploited. When you install SQL Server 2000 Pre-SP3 from disk your server will get pinged to death...this is why I disable the network connections while installing SQL Server until I can get it fully updated.
I recently installed QAAS Wall on one of my W2003 Servers and it works, but I'm having some difficulties getting the whitelist to work property. It keeps blocking access from one of my database servers.
Related
List of unidentified sql jobs
Our SQL Server 2008 R2 has lots of auto generated jobs from nowhere as can be seen from image above. I strongly suspect this causes our server password keeps reset daily for no reasons (I had untick those 'Enforce password policy' checkboxes). For now I had delete the jobs but I am not sure can this really solve the root of the problems. Any idea on this? Thanks guys...
Your server has most likely been compromised. The most appropriate thing to do in this situation is to either reinstall everything from scratch and restore your last known good data backup (prior to getting compromised), or perform a bare metal restore of the server from the last known good (uncompromised) backup. At this point you don't know what malicious software is still on that server, so you have to assume that it's riddled with it.
Do this after you've ensured that the server will be secured from network attacks and don't leave it exposed to the public internet. If it wasn't previously exposed, you may have malicious software on your company network.
I can't connect to my Azure SQL Database that I have hosted on MS Azure.I have tried with Visual Studio and MSSM with no luck.
I can't seem to work out how I could possibly be going wrong. I allowed access to the server on all IPs.
I am using the correct login info.
I dont seem to be even able to ping the server, despite it showing no issues in the Azure interface.
The server is located at: kkbpeyaf0t.database.windows.net
I tried to connect to the URL you provided using SSMS and it gave me a login failed (which I expected), so that tells me that the database is running and that you did indeed open up the IP ranges to allow anything (which isn't a best practice, but I'm assuming you did this as part of your troubleshooting). IF the Azure SQL DB firewall was still in the way it would block immediately indicating so.
I would think that if you have the correct username and password combination it should connect. Make sure that your outbound port 1433 isn't being blocked by your own firewall (machine, work, ISP, etc.).
Azure SQL Database won't respond to pings.
Docs can be found on MSDN.
I am having issues connecting to sql server either through SSMS or my C# application.
One thing to note is that I am out of my work domain. But I have in the past worked from home before and didn't had any issues. Maybe once but I restarted and it worked. But it's not working today.
Microsoft SQL Server ERROR 2
Establish whether the correct port is open and listening (TCP port 1433 by default) you may need to speak to your network administrator for this.
The SQL Server Browser Service may also need to be running.
If not the above then perhaps an authentication issue...
Finally managed to fix it. Logged on to sql server configuration manager and under sql server services I noticed that all the services were stopped. Just started the SQL Server (MSSQLSERVER) manually and everything is back to normal.
Thank you everyone for your time and input. Much appreciated.
I guess someone tries to logon to our sql server and error log is getting bigger. I am running out of space on hdd. What should be the solution?
Cleaning up error log regularly? Howto?
Disabling access to SQL server? For attacker IPs? For local use only? Howto?
Any other?
Regards,
Burak
we had a similar problem here, constant attempts to guess the systems password filled up the log to epic proportions.
you could disable external access via the windows firewall (if you're using windows SBS 2003) its fairly trivial but the end solution we opted for (because we still required external access ourselfs to the database server) was to change the default access port to SQL server; it seemed to stop alot of problems.
although if possible, I would also considering changing the architecture of your network slightly (sometimes this isn't possible if you have purchased some virtual machine from a service provider); moving your database server and disconnecting it from your hub/switch and plugging it into the back of your web server (if this is the ultimate use for your databases) so the web server acts as a type of proxy, prevent all external internet access.
Are you sure logins are the cause of the error-log growth? If so, you could disable remote logins:
Goto START --> Microsoft SQL server 2005 --> Configuration Tools --> SQL server surface area configuration
Select Surface area con figuration for services..
Select Databas engine --> Remote connections and choose 'local only'
Note, this will disable all remote connections to the database, so only change this if your application connects locally!
For emergency you execute sp_cycle_errorlog to start a new one, so you can delete the old one w/o restarting the server.
But the million dollar question is, of course, what is filling up the errorlog? What message shows up again and again? If you tell us that, perhaps we can help you fix the problem and eliminate the errorlog growth.
I'm running SqlServer 2005 express edition on my laptop for development purposes. It seems that when I open a connection to the database, the setup time is REALLY slow. It can take up to 10 seconds to get a connection. I usually have multiple connections open at the same time (Profiler, Development environment, Query Analyser, etc.) I have a hunch that the slow times are related to the fact that I have multiple connections open.
Is there a governor in Express edition that throttles connection times when multiple connections are made to an instance?
Update:
My workstation is not on active directory, and SQL is running mixed mode security. I will try the login with sql authentication. I am not using user instances.
Update2:
I setup a trace to try and figure out what is going on. When the connection to the database is opened the follow command is executed:
master.dbo.sp_MShasdbaccess
This command takes 6 seconds to execute.
I figured it out. The problem was I had multiple databases with AutoClose set to true. I shut it off in all my databases and the problem went away.
see this article for more info.
Are you sure the connection is the bottleneck? Is it your conn.Open() line that is taking 10 seconds?
AFAIK there's no governer anymore in SQL Express.
Now, are you on a Windows Active Directory Domain? If so, there might be an issue with your DNS or something that means the connection to the domain controller to validate your logon to the server instance is taking the time. I suggest you experiment switching the server over to use SQL Security, give the SA account a password, and try logging in as SA and see if that makes a difference.