I recently started looking into the new Policy Management in SQL Server 2008 and when I checked for compliance with the "Public Not Granted Server Permission" policy, my server failed the check. The reason was, and I am pretty sure this is the default, public has TCP Endpoint permission so that users can connect to the server. If I were to remove this, I would have to assign users individually the right to connect.
This seems silly to me. I cannot figure out why Microsoft would recommend changing this. I have no guest account, so only specified users can access the server. The server is behind a firewall, and only one subnet in the company can even access it. Does anyone have any insight on this?
Security best practices start with locking EVERYTHING down, then only opening up pieces as necessary to the people that actually need to get to it.
By allowing the "public" access to even connect, regardless of the fact that they don't have rights to do anything, opens the door just a crack. Sometimes, that's enough to exploit a buffer overflow or another type of attack.
UPDATE
A Login and a User are two different things. A login is server level, a User is database specific. Every User should have a corresponding login; but not every login will have a database user account.
Let's say you are using Active Directory integrated security; and you've assigned a particular AD group to have access to the server. Now, only some of those within the group may actually have access to certain databases. Those are the people you want to allow access to connect. Whereas the other members of the group don't have regular database user accounts.
By definition this is a problem as some of the group members can connect and list databases on the server even though they don't have access to any of those databases. That's the "crack" in the door I'm talking about.
If you can stop those people from even being able to connect then you've gone a long way towards securing your server.
There are other server level permissions that the Public role grants to logins. If possible, you should turn it off just like you would a guest account.
Related
I have revoked select permissions for a user in SQL Server and gave them access to one table but the user can still query all tables.
REVOKE SELECT ON "dbo"."TableName" FROM "Domain\user.name"
I have double and triple check all the permissions on both the login and user. Can someone please steer me in the right direction?
To identify all permissions someone may have in SQL, you have to look at:
The SQL Login configured for their domain login. Is it a member of any server-level groups? Does it have any server-level permissions?
What databases does it have access to?
Within those databases, what permissions does it have?
I'm guessing you've already done that. Next level:
Identify all domain groups for which SQL Logins have been created.
Determine which of these groups your user is a member of. Do the same checks as above, e.g. what can members of that group do in this SQL Instance.
Note that domain groups can contain domain groups. Depending on how in (or out of) control you Domain Administrators are, you could have crazy levels of nesting going on. And this is in the Domain, active directory, which you may or may not have sufficient access rights to review in detail.
Don't forget Local (that machine) groups, often set up by default. Is the user a member of a local machine group with elevated rights? You won't find anything out about this at the domain level.
This of course assumes that they are only using their own personal domain login, without aliasing, "Running As", SQL authenticated logins, application logins, and probably some even more obscure things I can't think of right now. (They probably aren't, unless they're griefing you.)
Note that this was off the top of my head. Configuring SQL Security is a Dark Art; figuring out who's been configured with what can be a nightmare (and worse when dealing with applications running on system accounts.) Good luck!
I just enabled remote connections on my SQL Server Express 2012 installation. Now I am a little bit worried about the server security because allowing connections to everybody sounds like a big security hole for me.
Is it possible to tell the SQL Server to disconnect if the user is trying to authenticate with a user which is not on my "allow" list? If so, I could add my monitoring user to this list and don't have to worry that my administration accounts are accessible.
First of all, this is probably a question that should be asked in the DBA site. Anyway, you can set up the security of the server so that only certain users are allowed to login.
When you set up the server, you add Logins to the Server Level and then Users at the database level. Only the users that are setup can, obviously, use a particular database. You can place users into roles, so, for example, they will have read-only access to a database. You can control, down to the object level, who has access to what.
There is a good article on what SQL Server security is about here
Having said that, sometimes, after, you have setup your security, you need to disallow certain users to not be allowed to Logon. Perhaps you are doing some major upgrade to the database. One option in this case is to create a Logon trigger.
A Logon Trigger will fire every time a user Logs in. You could create a table of "allowed" users and, in the trigger, if they are not in the table you ROLLBACK, effectively disallowing the Logon.
Here is information about creating a Logon trigger
You should be able to set up the db server to only accept connections from certain IP addresses, rather than to all of them. I'm unsure of the T-SQL syntax, but someone will surely chime in with the correct one.
If you really mean business, that being said, you'll want to authenticate clients using certificates that you give them. See this and the various articles it links to:
https://security.stackexchange.com/questions/14589/advantages-of-client-certificates-for-client-authentication
Being able to connect remotely to a SQL Server instance does not mean that they can Login to it. If they are not authorized properly, they should still get kicked-off by the SQL Server Login Authentication sequence.
This is silent/invisible for "Trusted Logins" (where the authorization comes from their Windows Login/Domain Account), but it still happens.
If you look under the "Security" folder of your Server (in SSMS), you will see the list of authorized Logins to you SQL Server. By adding or removing these you can control who can actually create a session on your SQL Server.
The title says it pretty well: I can access my SQL Server from the internet, and my users are configured with strong passwords to access only their respective DBs.
But I receive 10000+ login attacks by day with the user "sa".
I don't need "sa" remote access, how to disable it, and only it?
Thank you!
Security practices by Microsoft and industry state if use SQL authentication to rename the sa account and disable it. There is really no reason to use that account explicity for an application or admin account. Most companies require tracability when it comes to security and use of the sa account in SQL server does not allow for that.
Even if you disable or rename it you will still see attacks coming in for that account, it comes with the territory. The same thing occurs with the default login Oracle has in their product. Script kiddies and other hacking programs are just programmed to check for those type of accounts.
A better option might be to report where the attacks are coming from on the network side to your network team or ISP. They will be able to better handle that to block that traffic through the network layer. Just my opinion.
Perhaps this might help: in conjunction with this:
As far as i know SQL Server lets you diable single sql server logins, but that means the login is disabled in general, regardless of the machine the user is trying to connect from. So you either disable "sa" in general or you'll have give the login a really strong password. You might be able to emulate the desired behavior by using a logon trigger, that checks where the user connects from, if the user is "sa", but i think that's not a viable solution for you, since you seem to be wanting to get rid of the many connection attempts from attacks. In any case, you might want to remove "sa" from the server role "sysadmin" to guard against a potentially successful login attemt.
I've been searching hard to get my head around security related issues in a SQL Server.
We're developing a .NET application that targets SQL Server 2008 and we want to use FileStream.
Now I've found out that SQL Server only allows FileStream through the Win32 API if you use Integrated Security. The problem is that we have around 80% of our application finished, but it is entirely based on SQL Authentication. So we are doing INSERT's straight form our application and are not using Stored Procedures for every CRUD operation.
This is relatively safe because I can store the the SQL username and password in an encrypted form. I know the password is transported in Clear Text, but I'm willing to accept that.
We want end-users to be able to connect to the databse through tools such as Crystal Reports and for that we have an extra SQL login that has only SELECT-rights granted.
Now, if we change to Integrated Security we would have to give individual users (via AD groups, etc.) rights to do the things the application can do. Otherwise the application would not be able to do it's work. But then the end-user would also have these rights when he connects straight to the DB.
I see people saying that you should use Stored Procedures for every CRUD operation and grant the EXEC-rights only to the AD-group, but how would I do this? I do not see how a user would have different authorizations when he connects directly or through the application... Can anybody enlighten me on this.
An extra question for bonus-points: Intergrated Security will not work on a Workgroup as far as I understand. How do people get FileStream to work in a Workgroup then? Or is this considered an impossibility?
Integrated security WILL work in a workgroup, using the legacy mechanism, where you have a matching username and password on the two machines. Also, a domain user can use the legacy mechanism to log into a non-domain server if the server has a matching user account.
Integrated security can even work with non-matching usernames and passwords. This may help you in your scenario.
Try this:
NET USE \\DBSERVER /USER:DOMAIN\USERNAME
You will be prompted for your password. This establishes a NetBIOS session with the database server. You should be able to see the shared folders and shared printers on the database server once you have done that.
Once a netbios session has been established between the client computer and the database server, you will THEN be able to use integrated security without being prompted for a password.
You may have to specify "named pipes" as the network protocol to usem, if it doesn't work with TCP (but I think it will). Named Pipes inherits your existing NetBIOS session, so provided you can list the shares you are probably good to go.
You can also establish the logon session using the windows API function NetUseAdd with USE_INFO_2 (level 2) information which incorporates the password.
I guess the short answer then is that you can have a special Windows logon for your application and have the users log in using that. However note that they cannot also be connected to the same server using their own username and password.
So far, after creating DB with all the schema, all I have done so for was accessing them (tables) by reference through ConnectionStrings.
Now, twice, I've read that it's better to create a DB user and access the DB trhough that user by including him in the connectionString.
I'd like to know why so?
Thank for helping
Your question isn't that clear. It seems that you're asking if it is better to use windows security ("Integrated Security=SSPI" in the connection string) or a username/password ("User ID=myUsername;Password=myPassword;").
Its always better to use windows security. Having login information within the connection string is a security risk. Its in cleartext (unless you take some complicated steps to secure that section), and is sent across the wire as cleartext unless you set up a trusted connection between application and server.
Is it better to "create a db user and access the db trhough that user by including him in the connection string?" No. Its better to create a sql server login for user's windows identities and let them use those credentials to access the server.
You do this if you wish to connect as a specific user, rather than (for example) just using the context of the current user which your application is running under. However, if you use SQL Server authentication (i.e. username and password), you'd need to provide that password in the connection string, which is something of a security problem.
If the application has a group of anonymous users (or manages users/passwords itself) then its better to use a Windows login and run the application under a service account (which has minimal required access to the database).
If you're running an interactive application on the desktop, you should let those users connect to SQL server in their own context, by adding them to SQL Server with the required rights (e.g. db read/write , remove any higher functions). Obviously you would use groups to make administration simpler rather than adding individual users.