 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / General / Security / October 2005sa loginname being hacked
Hi, Is there a way to change the sa as loginname? At work we are getting haked by 'brut-force', every second we are beinbg attacked with sa and a password. It's a matter of time when the password will be hacked, so changing the password isnt a solution. If we also can change the sa loginname we will be better of. Or is there something else we can do to prevent the hackers to get our sa password? Many thanks Lookup sp_password stored procedure in the BOL > Hi, > [quoted text clipped - 8 lines] > > Many thanks I know I can change the password...thnx > Lookup sp_password stored procedure in the BOL > [quoted text clipped - 10 lines] >> >> Many thanks October 16, 2005 Don't you have a router in place between the SQL Server and the outside world? Can't you trace where the packets are coming from and block that IP/Domain name?  SignatureJoseph Bittman Microsoft Certified Solution Developer Microsoft Most Valuable Professional -- DPM Web Site: http://71.39.42.23/ Static IP > Hi, > [quoted text clipped - 8 lines] > > Many thanks Yes, we did. We know one of their IPs and blocked it... But they are using now another IP (IPnumber 9 and 3 different domains also!!...:-<) It takes a lot of work every time blocking another IP of theirs.... So the easy thing for us is to just simply(??) change the sa loginname into something else. But I guess that's not possible?? We cant change our Domain name or SQL server name also...!! Why cant I change the sa loginname??? thanks for the help Joseph > October 16, 2005 > [quoted text clipped - 14 lines] >> >> Many thanks Am Sun, 16 Oct 2005 18:41:40 +0200 schrieb Pipo: > Yes, we did. We know one of their IPs and blocked it... > But they are using now another IP (IPnumber 9 and 3 different domains [quoted text clipped - 26 lines] >>> >>> Many thanks Is your traffic between clients and Server encrypted? If not they can find login and passwort in clear text in the traffic. I can highly recommend to use a simple VPN-Server and allow connections from outside only over VPN! bye, helmut Thanks for the answer Helmut, but we cant do the VPN solution you suggest. Yes, it is encrypted, they dont have the password yet!!! But if we dont do anything about it they will get it. For now we change the password every 5 minutes but we need more securit y. So changing the sa loginname will be a good place to start, I cant figure out why I cant change that loginname!!! (like in Oracle!!) Or give the sa user no more rights and create my own 'sa'...:-s But I guess that the security of SQL server isnt that good or I am wrong????? > Am Sun, 16 Oct 2005 18:41:40 +0200 schrieb Pipo: > [quoted text clipped - 38 lines] > > bye, helmut Have you considered Windows Authentication? SignatureHope this helps. Dan Guzman SQL Server MVP > Thanks for the answer Helmut, but we cant do the VPN solution you suggest. > Yes, it is encrypted, they dont have the password yet!!! [quoted text clipped - 52 lines] >> >> bye, helmut What do you mean by that? I still have the sa account which is active....so they still can get in via the sa account. > Have you considered Windows Authentication? > [quoted text clipped - 54 lines] > >> > >> bye, helmut Non-trusted connections using the standard SQL 'sa' login are not allowed when SQL Server is configured for only Windows authentication. This is the most secure authentication method. SignatureHope this helps. Dan Guzman SQL Server MVP > What do you mean by that? > I still have the sa account which is active....so they still can get in [quoted text clipped - 66 lines] >> >> >> >> bye, helmut I understand. Thanks > Non-trusted connections using the standard SQL 'sa' login are not allowed > when SQL Server is configured for only Windows authentication. This is the [quoted text clipped - 70 lines] > >> >> > >> >> bye, helmut October 18, 2005 lol I didn't set this thread to 'watch' so I lost it.... How are they being allowed to hit the SQL server with requests? SQL Servers should not be directly accessable from the outside world, and should have a web server or some other server in place to receive the requests first. I would block all traffic going to XXXXXX IP (your SQL Server's IP) from the outside network, and then implement another router or somewhere which allows only traffic from XXX IP (your web servers). I don't believe you can change the sa account name, as toooooo many programs rely on it as the 'default' name. Hope this helps! SignatureJoseph Bittman Microsoft Certified Solution Developer Microsoft Most Valuable Professional -- DPM Web Site: http://71.39.42.23/ Static IP > Yes, we did. We know one of their IPs and blocked it... > But they are using now another IP (IPnumber 9 and 3 different domains [quoted text clipped - 26 lines] >>> >>> Many thanks Do realize how insane it sounds to say "SQL Servers should not be directly accessable from the outside world" -- cause when Microsoft first developed SQL Server they said EXACTLY the opposite of what you just said. Come on guys/gals, we need real solutions not "you can't do this and you have to jump thru this hoop". It is getting real frustrating seeing these standard responses -- so why does SQL Server even respond to a port and public IP address? Why build the functionality if one is NEVER supposed to use it to the big scary outside world -- hell may as well just do IPX/SPX. And please no more "and that's just the way it is" > October 18, 2005 > [quoted text clipped - 40 lines] >>>> >>>> Many thanks October 18, 2005 Sorry, Rob.... I have read over 1600+ pages of MSPress security and I have never read anything to back up your claims. A SQL server should not be exposed for requests from outside the network. Applications should be designed to go through a web server (or web service) and then have the web server/service make a request to the SQL DB. Then it should return the data to the client. I can't think of one well designed enterprise application which would need to have SQL exposed to the outside. Also, with requests continually hitting your server, there is a great possibility for a DoS attach. Also it takes up a lot of network bandwidth which would never be acceptable on an enterprise level. I just can't agree with your opinion without further evidence from you to back up your claim. Have a great day! SignatureJoseph Bittman Microsoft Certified Solution Developer Microsoft Most Valuable Professional -- DPM Web Site: http://71.39.42.23/ Static IP > Do realize how insane it sounds to say "SQL Servers should not be directly > accessable from the outside world" -- cause when Microsoft first developed [quoted text clipped - 54 lines] >>>>> >>>>> Many thanks Not sure I understand, DoS attack could happen to any door open to the public port 80 or port 1433 or whatever port is being used. IP Spoofing is the real issue and you should know that as long as IP spoofing is a reality, the sheer volume of hackers will persist from now til we finally get off TCP/IP and onto something truely secure and accountable. What your suggesting as better approach is based purely on Security -- I don't see how adding a layer in the data chain is going to help performance? If the layer is added purely for the sake of security, then the flaws in the design lay elsewhere (and I think we all know where). I don't buy into the "build another layer" philosophy on any scale. I have client's with MS Access databases (they come and go and their IPs change regularly and VPN is not a possibility for my clients). I install a service on their PC that gathers the MS Access data and communicates with a SQL Server. I have anonymous web users that communicate with my web app via a web server which in turn updates the same SQL Server which in turn is queried by my client's remote PCs to update their MS Access database. Why should I add another layer (web service) running on a web server? If your ONLY reason is security, then ask yourself why? My business logic is removed in my remote PC Windows Service and in the logic used by my web application -- I have real Windows applications (remote PC) running an interface to the MS Access data and I have Web Server applications running an interface to the data. My Windows Service running on remote PC's bridges the MS Access and SQL Data (two way). I for one do want additional layers to manage and I don't want the performance hit either and certainly not in the name of security. > October 18, 2005 > [quoted text clipped - 70 lines] >>>>>> >>>>>> Many thanks Rob, What do you suggest instead? Renaming the "sa" account doesn't help, since people will just keep guess at "sa" (thus consuming resources) or attempt to guess both the username and the password (thus possibly compromising the database server). As suggested before: VPN is a tried and trusted mechanism for making this work (and it's not just in the SQL Server world, but anywhere where disparate client systems need to communicate over a public network with a remote backend service). VPNs have been around for years, and are used for exactly the types of situations you have described (a client machine running a client like Access or similar connecting to a backend DB Server). There's a VPN client built into Windows (and most other OSes), and a VPN Server (Routing and Remote Access Server) built into Windows Server. An alternative is using Window Auth only. Cheers Ken : Not sure I understand, DoS attack could happen to any door open to the : public port 80 or port 1433 or whatever port is being used. IP Spoofing is [quoted text clipped - 99 lines] : >>>>>> : >>>>>> Many thanks Pipo, Use a long password -- it maybe a matter of time, but even at login attempt every 1 second it would be several million years before they'd even reach the 1/2 way point in possible combinations -- do the math, you can figure out how long it would take to process every possible combination. These types of hackers are really pretty stupid -- I find them annoying because of the resources they use on my SQL Server and bandwidth. I do a daily check using netstat -n and then just add new SQL hacker IP addresses to my IPSec blocking configuration. I'm coding a solution that can update my IPSec dynamically and re-open blocked IPs when/if they come clean -- couple of days coding in what little free time I have. Tis an annoying problem for sure and 90% of the attacks are from foreign countries (I live in the US) with the majority coming from Korea and few from Russia -- Russian attacks are easy to spot for me, takes them a good 10 seconds before they can even re-attempt a login. I'm also setting up an bait and trap SQL Server with fake CC info that is REAL easy to get into (not too easy or else the hacker may get suspecious) and then waiting for the 'real' identity to attempt to get in and extract data (also coding a program to help me with this on my own time) -- you might say I'm getting personal about these attackers. Hey someone has got to do it since Microsoft have dropped the ball and don't seem that interested. Of course, with IP spoofing nothing is really secure or guaranteed -- this is just to identify the lame hackers, but since most are in Korea it ain't like anything can be done about it (although I do have some ideas -- bait CC/SS numbers that when used request arrest of the person using it -- ya know, all the typical things that SHOULD be happening at large corporations and banks that have the resources but don't implement anything but do charge you for anti-identity theft). Rob. > Hi, > [quoted text clipped - 8 lines] > > Many thanks Yes, a riddiculously long password can make it difficult to get in though it will still burn up a couple of cycles rejecting the wrong password. Can't disable or rename SA in SQL Server 2000 but you can rename in 2005. In the meantime, you can consider having SQL Server listen on a different port if you can control how the users/apps will access SQL Server. Not a foolproof solution but it makes it just a tad harder for the average script kiddie since they're likely scanning default ports. Auto blocking of IPs can be tricky to do right especially if the attacker is smart about spoofing and the auto-blocker might block valid addressess (that were temporarily spoofed). SQL Server isn't so bad. I grew up with Oracle then moved to SQL Server. I thought it was bad that Oracle had a handful of high permission accounts that are left active on the server after they're used for the installation process. When Oracle locked things down in 9i, I discovered there were almost 20 such accounts (I only knew of a few before that). Point is, many vendors were not as diligent back then as they are now. I can't think of anyone that's guilt free. Btw, your "bait and trap" is also known as a honeypot and has been used in many agencies for a long time. It can be amusing watching them wander around in your maze if you've got the graveyard shift and everything else is running fine. :-) joe. > Pipo, > [quoted text clipped - 44 lines] >> >> Many thanks |
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
|
©2010 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.