 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / General / Security / October 2005Is there any way to prevent hacker trying to guess sa password?
Some hacker has set off a program to try and guess the sa password to my SQL Server that is public (1433 is open) -- I'm logging all the attempts (about 6 a minute from the start of my logging til now -- several 100,000 combinations and counting. Is there anyway to detect the source IP and block/shut it down? Thanks, Rob. Nothing built into SQL Server 2000 - you have to get at this through the OS level using Network Monitor or another sniffer to capture the IP of the source. -Sue >Some hacker has set off a program to try and guess the sa password to my SQL >Server that is public (1433 is open) -- I'm logging all the attempts (about [quoted text clipped - 4 lines] > >Thanks, Rob. Hi Sue, I don't suppose Microsoft provide any such easy to use tools to monitor "patterned" network traffic -- i.e. the same IP attempting connection with my SQL Server every 10 seconds? Also is there anything in SQL Server 2000 that can filter out an IP that attempts more than XYZ failed attempts at login with sa? It seems that 95% of hacker activity/patterns are very similar, but I'm not finding anything in the MS 2003 Server nor in MS SQL Server 2000 that would help identify and prevent these patterns -- am I just missing something? If not, are there any tools out there (paid or free) that are easy to use with minimal setup -- I'm a developer and don't have the time to spend on tracking stuff like this down and I've got more important task to accomplish with looming deadlines. Any recommendation, tips, hints, web sites to visit would be most appreciated. Thanks, Rob. > Nothing built into SQL Server 2000 - you have to get at this > through the OS level using Network Monitor or another [quoted text clipped - 12 lines] >> >>Thanks, Rob. Is is absolutely required that port 1433 be open to the entire internet? If not, why not use a firewall or similar to block all IP addresses except those that should be permitted access? Cheers Ken : Hi Sue, : [quoted text clipped - 34 lines] : >> : >>Thanks, Rob. Hi Ken, The problem is, those that should be permitted access are not static IPs (they could be a broadband connection with a dynamic IP) -- IPs can and do change so that would involve a lot of maintenance to keep them updated not to mention the end user would NOT have a clue what is wrong with the applicaiton that no longer can communicate to the SQL Server. Is there really NOTHING built into Win2K3 or SQL 2000 that has any intelligence about prevent hacker attacks? I mean the pattern of a SQL hacker is pretty simple -- look in the event viewer at the 20000+ login sa failed attempts (once every 10 seconds). What I don't like is the processing time the hacker consumes with all the failed login attempts -- with my 40 character password at one attempt every 10 seconds it would still take them 5.6034833284317069404025203533663e+87 years to guess the password -- even assuming they got lucky and hit the jackpot in 1/2 the time that is still 2.8017416642158534702012601766831e+87 years. So am I worred about using port 1433, no -- just annoyed that there doesn't appear to be any tools to automatically ignore these attempts and stop using up my bandwidth and resources. Rob. > Is is absolutely required that port 1433 be open to the entire internet? > If [quoted text clipped - 50 lines] > : >> > : >>Thanks, Rob. Hi Rob, I have the same situation, till now all my clients uses a fixed ip address and my firewall is in stealth mode and talks only with privileged addresses, so i had no attack till now on my SQL-Server, but in my next project i have clients with dynamic addresses too. So i am very interested in this article and hope for some tips. In the moment i am trying to find out if VPN can help me. Yes, the VPN Server can be attacked too. And there is no shelter against DoS. But then this is handled (i hope very efficient) by the router and is not stressing the SQL-Server or the valid connections. The one and only really 100% save solution would be a leased circuit, because: no connect to outside = no attack from outside ;-) But this is to expensive for me. bye, Helmut VPN can help but I found it caused more maintenance (in terms of network quirks, slow boot problems, incompatibilities with some remote PCs and very sensitive to any Windows updates) than it was worth. I think the only other "secure" way is via XML/SSL and have an applicaiton server level where the remote users communicate requests to the application server which then has a local link to the SQL Server -- that way you can a public web server talk to the application server and remote clients talk to the application server and keep the SQL server relatively safe behind the applicaiton server. Definitely NOT the easiest approach and certainly NOT the fastest approach but pending the scale of you user base and/or solution(s) it maybe more appropriate. I know SQL 2005 is supposed to be much better but I'm not clear on the upgrade path and from what I've heard migration and knowledgebase required to keep a SQL 2005 server going is well beyond the capacity of a developer who IS also the DBA by default cause nobody else is qualified and/or no money to hire someone that is qualified. Ross, sorry for the same questions -- perhaps I'm just in denial that the OS (even Win2K3) and SQL 2000 (with all the various SPs) are still so unintelligent about monitor and defending against your typical hackers. Maybe I'm just frustrated that MS don't appear to progressing in this area -- it seems security is getting overly complex when it should be getting more secure and easier to implement -- but I'm not an IT guy so I'm sure I'm missing something. Rob. > Hi Rob, > [quoted text clipped - 14 lines] > bye, > Helmut Am Tue, 11 Oct 2005 16:35:39 -0700 schrieb Rob R. Ainscough: > VPN can help but I found it caused more maintenance (in terms of network > quirks, slow boot problems, incompatibilities with some remote PCs and very > sensitive to any Windows updates) than it was worth. I think about a complete hardware solution. The hardware is really cheap compared with the costs for setup and/or other problems which can happen if using the windows-built-in-vpn. > I think the only other "secure" way is via XML/SSL and have an applicaiton > server level where the remote users communicate requests to the application [quoted text clipped - 4 lines] > the fastest approach but pending the scale of you user base and/or > solution(s) it maybe more appropriate. Definitely not possible for me. I would have to rewrite the whole application in a new technologie where i have no experience, and this on client side and on server side. But i like the idea from Ross Presser. I could easily write a little programm which is listening on another port. And the client has to send its ip in a special encrypted way, then my listener will open the firewall for this ip, otherwise no response from the listener - undetectable for hackers, i think. That is an interesting approach -- definitely worth consideration assuming your firewall will allow your code to open and change permitted IPs. Certainly worth the coding effort. Rob. > Am Tue, 11 Oct 2005 16:35:39 -0700 schrieb Rob R. Ainscough: > [quoted text clipped - 32 lines] > this ip, otherwise no response from the listener - undetectable for > hackers, i think. > Is there really NOTHING built into Win2K3 or SQL 2000 that has any > intelligence about prevent hacker attacks? No. And this question comes up in this newsgroup every few months, it seems like. (Perhaps there is a security tool which could detect and prevent that at the news server? :-)) > The problem is, those that should be permitted access are not static IPs I'll give the same suggestion I gave last time. Many firewalls have the ability to open a port to a specific IP after that IP has logged in in some way. Often (I'm thinking of Checkpoint FW1) the login is very simple, requiring only a telnet to another specific port and a short exchange of username and password - easily automatable. : Hi Ken, : [quoted text clipped - 3 lines] : to mention the end user would NOT have a clue what is wrong with the : applicaiton that no longer can communicate to the SQL Server. Fair enough. : Is there really NOTHING built into Win2K3 or SQL 2000 that has any : intelligence about prevent hacker attacks? What is a hacker attack? 3 tries in 1 second? 10,000 tries in one second? What you want is something like an IDS (Intrusion Detection System), which you can configure at an appropriate thresh-hold which you determine. Then it can do various stuff (like alert you, or configure a block at your firewall or whatever) when a trigger value is reached. However this is something that requires you to think carefully about it - to ensure that a legitimate user doesn't accidently lock themselves out. : I mean the pattern of a SQL : hacker is pretty simple -- look in the event viewer at the 20000+ login sa : failed attempts (once every 10 seconds). Is this just one IP address? If so, just use TCP filtering in Windows server. 20,000 attempts to pretty obviously a hack. But what if it was only 5 attempts? What then? In any case, this is probably something you should use something else to secure - firewall, VPN etc. Cheers Ken What I don't like is the : processing time the hacker consumes with all the failed login attempts -- : with my 40 character password at one attempt every 10 seconds it would still [quoted text clipped - 61 lines] : > : >> : > : >>Thanks, Rob. Simple option that the DBA can configure only permit login attempts every XYZ milliseconds, attack can be user defined -- you listed the paramters # of failed tries over XYZ milliseconds -- that'll cover the basic attacks at least, now the SQL injection attacks and/or crash the service attacks need to be address separately (no real DBA options here). But one would HOPE that Microsoft are serious about security (they certainly are having problems demonstrating this and have a serious problem with making joe consumer feel "safe") and would have considerable knowledge base on how hackers typically attack. But more importantly MS strategy should not only be to prevent, but to identify, locate, shut down and report to the authorities (regardless if this is some poor souls hijacked PC and has no clue what it is being used for). If MS wanna get true consumer penetration beyond 1 in 5 poople have a PC and even less venture on the Internet (we should be 1 in 1 or even 2 in 1 similar to TV sets) they NEED to come up with these types of solutions -- consumer confidence is extremely low whenver anything MS is mentioned. Getting consumer confidence back into MS products will benefit everyone involved and may just bring back the much lost life after .COM crash. I know a little rant, but something NEEDs to be done and if locking out a legit user because they try 50 times with the wrong password over 1 minute period the so be it -- but Zoom out and look at the big picture, a few users locking themselves out because they trigger a hacker switch vs. millions of potential users living in fear of the PC and the Internet. I'd take locking out the really stupid user any day. But that is my point, I have a 40 character password, it is secure (with the exception of hackers crashing the service which is beyond my control) and my sensitive data is 3DES encrypted in the database so if entry did happen they'll not have access to any useful data. But I think the point of telling the DBA, or Developer or IT person "security isn't MS problem, it is yours" does NOBODY any good. MS needs to provide these tools, they need to get serious about security, they NEED to understand that DBA's, Developer's, IT people can and do go the easiest route to security -- it doesn't matter what the DBA, Developer, IT person does or doesn't do, the ultimate perception of being hacked or security compromised will point to MS in the public eyes -- so for MS to say it is NOT our burden is just foolish. I realize this is falling on deaf ears, but MS need to stop the ignorance -- provide the tools, make them easy to use, provide intelligent defaults to configurations. > : Hi Ken, > : [quoted text clipped - 125 lines] > : > : >> > : > : >>Thanks, Rob. : Simple option that the DBA can configure only permit login attempts every : XYZ milliseconds, attack can be user defined -- you listed the paramters # : of failed tries over XYZ milliseconds -- that'll cover the basic attacks at : least, now the SQL injection attacks and/or crash the service attacks need : to be address separately (no real DBA options here). The proper way to secure this though isn't in SQL Server per se. Whilst that might be a "nice to have" feature, I think I'd prefer the SQL Server product group to work on more important things. There aren't that many application servers that limit the number of logons/sec (e.g. Active Directory doesn't, IIS doesn't, SQL Server doesn't, Exchange doesn't). Instead, you should use an appropriate tool for the job. By using the most appropriate, dedicated tool, we keep things a little simpler and the network easier to manage and defend. : But one would HOPE that Microsoft are serious about security (they certainly : are having problems demonstrating this and have a serious problem with : making joe consumer feel "safe") Microsoft's putting a lot of effort into security. Check their website someday and look at all the consumer guidance they have out there now. Look at all the tools that have been coming out (MBSA, IISLockDown, AntiSpyware, Malicious Software Removal Tool). Look at the improvements in security in SQL Server SP3, and IIS6.0 etc : But more importantly MS strategy should : not only be to prevent, but to identify, locate, shut down and report to the : authorities Microsoft does have a honey pot project running. And I'm sure they have contacts with various authorities to report on the more significant issues. : But I think the point of telling the DBA, or Developer or IT person : "security isn't MS problem, it is yours" does NOBODY any good. Ultimately, security is your responsibility. There are tools out there (like firewalls, IDSes, and the stuff built into SQL Server). But how you configure it, and the processes you use to manage it are your responsibility. : MS needs to provide these tools, The tools are there - you just aren't using them. And blaming Microsoft isn't going to solve the problem. You think you are the only person in your situation? There are lots of companies running SQL Server, but they don't all seem to be having the problem you are having. You need to do a little research, and get the necessary info on how to configure all this stuff properly so you don't have this issue. And frankly, your lockout system is a little scary - you want to lockout the "sa" account? Sounds like a potential DoS issue to me. Cheers Ken : they need to get serious about security, they NEED to : understand that DBA's, Developer's, IT people can and do go the easiest [quoted text clipped - 134 lines] : > : > : >> : > : > : >>Thanks, Rob. Ken, As much as I'd love to have the time to do a little (actually A LOT) research, I don't have the time. My point is that Microsoft should know by now the most predictable and common security issues -- be it poor setup/configuration (again intelligent use of default configurations would be good). Having a SQL Server or several should NOT need a "security team", a "database team", a "network team" -- if this is what it takes to secure a network and/or SQL Server then that IS a problem. If I could remove the sa account, I would -- but I can't when in mixed mode using SQL Authentication -- again not my design. What is scary is that opening port 1433 is some "major" security flaw -- it shouldn't be and if it is why -- because hackers can crash the service with port on -- again why is this my problem, shouldn't the service be secured by MS -- they coded it. I think part of the problem is that you're used to "living with" the security problems and the many possible solutions and working around to them all. Smaller companies don't have the luxury of hiring multiple security/network "experts" in order to secure data that in most cases affects the end user (our clients/consumers) and forces them to conform just because MS can't provide a simple secure solution. Adding yet more tools on top of the tools is not really helping the situation, just more things to configure and to manage and to purchase because of either the OS/SQL weakness. In fact, by me posting on this very newsgroup, I'm now being flooded with "security experts" wanting a job. Having numerous experts doesn't help make a product cheaper to the end user/consumer. I shouldn't need to go to a bookstore and see 150 books on securing Microsoft OS/SQL Server -- in a word, I don't have time to read them all -- I'm a software engineer with bigger fish to fry. If I wrote software that expected my end users/consumers to go read several books on how to use my software efficiently, I'd be out of business. Rob. > : Simple option that the DBA can configure only permit login attempts > every [quoted text clipped - 232 lines] > : > : > : >> > : > : > : >>Thanks, Rob. : Ken, : : What is scary is that opening port 1433 is some "major" security flaw -- it : shouldn't be and if it is why -- because hackers can crash the service with : port on Remove the TCP/IP library, and port 1433 will not be open. Your clients will need to use some other mechanism to connect to SQL Server. Having port 1433 open is completely different to guessing the "sa" password. If someone can crash SQL Server by connecting to port 1433, you need to open a case with Microsoft PSS to get that fixed. : I think part of the problem is that you're used to "living with" the : security problems and the many possible solutions and working around to them : all. Not at all - I realise that you use the most appropriate tool to do the job. Glass windows can be broken - do we demand that all glass window manufacturers now work out how to prevent an attacker from breaking your house's glass windows? No. You use shutters, steel bars or a burgler alarm system. Use the right tool for the job. : Smaller companies don't have the luxury of hiring multiple : security/network "experts" in order to secure data that in most cases [quoted text clipped - 3 lines] : configure and to manage and to purchase because of either the OS/SQL : weakness. You don't need multiple security experts. Just put a very complex password on your "sa" account. Or don't expose port 1433 to the internet directly. There are lots of simple "solutions" to this problem. :: In fact, by me posting on this very newsgroup, I'm now being flooded with : "security experts" wanting a job. Having numerous experts doesn't help make [quoted text clipped - 4 lines] : users/consumers to go read several books on how to use my software : efficiently, I'd be out of business. If you wish to use a complex piece of software like SQL Server, you should have some basic level of knowledge. You should expect to do some reading on the product, and expect to have some kind of learning curve. No one is suggesting you need to read 150 books. Cheers Ken : Rob. : [quoted text clipped - 234 lines] : > : > : > : >> : > : > : > : >>Thanks, Rob. Ken, I don't think your analogies are appropriate -- but if you think they are, the Space Shuttle has some very strong windows -- get my point. Putting bars on my house -- who's really the prisoner? I have a very complex sa password and the real problem is to stop the hacker from using resources on my SQL Server for failed login's every second or so -- bandwidth and server time IS the problem, the hacker will never (in my life time) be able to hack the password so that is not the issue. And I've read way more than I should need to, but as I'm discovering the real problem is 'IP spoofing" which points to TCP/IP which is obviously a seriously flawed communications protocol -- any protocol that permits the manipulation of the source address in the IP packet header is without a doubt THE single most significant security flaw -- this is the green light for Hackers. If this problem isn't resolved, then everything else that is done in the name of security is really just circling around the problem and a waste of time. What IS scary, is that this is NOT new news and IP spoofing was known about when the protocol was introduced and Microsoft did NOTHING in their OS to prevent it. So lots of very highly paid people making some really bad assumptions and/or taking short cuts -- not entirely blaming Microsoft, but at the time they were THE company that could have and should have prevented this major flaw and worked with NIC companies and the host of other companies involved in the game of public data transmission. Human history is very predictable, leave any door open and it will be abused -- that's what humans do. Rob. > : Ken, > : [quoted text clipped - 347 lines] > : > : > : > : >> > : > : > : > : >>Thanks, Rob. Rob, I have been down this road - you can use SQL Profiler to record unsuccessful login attempts. You can include the login (such as sa, admin, root, are the common ones they try). When you see a break in attempt you can run netstat or netstat -n. Look for entries that are for ms-sql and that say "Time Wait". The hackers will be obvious. You can then block that IP (use a firewall or local security policy). You may need to do this several times per day as new drones are coming online all the time searching for SQL servers. They will never be able to guess a strong sa password but they can use up a lot of bandwidth trying. Microsoft refuses to fix this in SQL 2000 - you cannot rename the sa account or delete it or stop continuous login attempts. Microsoft has fixed the problem in SQL 2005 - due to be released next month. It allows you to use the OS features - ie - you can allow say 5 unsuccessful logins then block them for 30 minutes (or whatever you specify). This totally fixes the bandwidth issue for nerds trying to login as sa, root, admin, etc. Of course if someone is trying to login with a login that you actually use, you can end up locking yourself out - but you shouldn't be using the sa login for anything anyway. Russ Stevens Russ, What is the migration path like to SQL Server 2005? I've got the betas but have not installed or tested with it. How is installation and setup? Any connection issues with ADO.NET? Do I need to change my connection string? I don't use sa period (with the exception of automatic database builds from scratch -- this is rare), I setup my own SQL Server accounts and use those. I don't like to use NT authentication because I don't want a hacker gaining access to both SQL server and the OS just in case they were able to guess the password. I do write to event log with failed logins with sa and that is how I know there is some drone attemtping to get in, but thanks for the tip on netstat -n, I will try that out. Thanks for your suggestions, Rob. > Rob, > [quoted text clipped - 19 lines] > > Russ Stevens Rob, <<What is the migration path like to SQL Server 2005? I've got the betas but have not installed or tested with it.>> From what I have read (I have also gone to a couple of SQL Server 2005 Intros) you can upgrade directly or install side by side with SQL 2000. Or, you detach all of your databases, uninstall 2000, do a fresh 2005 install, then attach all of your databases - of course, you would then need to setup all of your logins again. The last approach is what I did with the Beta just to play with some existing apps. <<How is installation and setup?>> I just tried one beta - went just fine - there are a lot of issues for users that have used more than one beta - it is important to uninstall stuff in the correct order and get matched sets of VS2005. These issues should be na for the shipping product. <<Any connection issues with ADO.NET? Do I need to change my connection string?>> My apps were totally non affected - same connection string. I tried VB6 apps and .NET 1.1 Apps - both were fine. Of course if you upgrade a .NET app from 1.1 to 2.0 there are lots of new features in ADO but that is more a VS2005 issue than a SQL server issue. <<I don't like to use NT authentication because I don't want a hacker gaining access to both SQL server and the OS just in case they were able to guess the password>> Yes - but you use NT Authentication to do your maintenance, run Enterprise Manager, etc. That way, you do not need the sa account - give it an impossible password. If 1433 is open, deleting or renaming the sa account doesn't do much good (same as an impossible password). The hackers will still use the bandwidth trying to login to a non existent account. ie - we don't mind them trying a couple of times - but 24 hours at 50 times per second is ridiculous. The number of attempts per second depends on how many drones are attacking you at once and whether they are coming from a dialup or another server that has a high speed Internet connection. If you go to task manager (Win2003) and look at the networking tab and see a straight baseline of bandwidth that never goes down, then you are probably being attacked. I have done some research and called a few vendors - programming firewalls, etc. The bottom line is that buying SQL 2005 is a whole lot cheaper and more effective than some of the other alternatives that are being suggested. SQL server was designed to be open to the Internet (regardless of what others may tell you). However, some company created an sa account that had full access. That same company tells you to rename the admin account on your server for security reasons (hackers then need to guess an account and a password instead of just a password) but doesn't allow you to rename or delete the sa account. Then to compound confusion with commotion, that same company made the default sa password a BLANK. This started an entire hacking industry of going around and checking port 1433 and trying to log in as sa with a blank password. That company finally issued a service pack so that an sa password was required for an install, but by that time, all the hackers were then also using dictionary attacks to guess the sa password. And other than forcing you to buy the product all over again, that same company refuses to fix the problem. Russ Stevens The only thing you said that has me a little worried: >> Of course if you upgrade a .NET app from 1.1 to 2.0 there are lots of new features in ADO but that is more a VS2005 issue than a SQL server issue. << Are these new features REQUIRED to make the ADO connections work? or just features that I can enable/disable as needed? But since .NET v1.1 has no issues with SWL 2005, then I'm ok with that. I think I can sell the SQL 2005 upgrad to my clients -- just show them the hackers consuming all that bandwidth that they're paying for. Rob. > Rob, > [quoted text clipped - 62 lines] > > Russ Stevens Rob, You might want to watch the "Whats new in ADO.NET 2" at http://www.ftponline.com/channels/net/reports/vsliveor/2005/perret/ Also the video at http://www.ftponline.com/channels/net/reports/vsliveor/2005/vaughn/ Russ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.