I have had responsibility thrust upon me for three apps which will all use sql server ..... One will exist partially outside of our private network in a DMZ the other two will be on our private network. All three will access databases on the same machine inside of the private network. I am assuming that MS SQL Server can manage more than one database at a time ..... my question is this ....outside of users and groups .... is there any other functionality that would protect my other two databases should the machine in the DMZ be compromised? What I am hoping for is functionality that would limit database access by ip address as well as user name ....any thoughts?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SECURITY QUESTION 1
- Thread starter cDevX99
- Start date
If you are going to use an .asp page, then yes, you can check for the IP address on that page and let certain users access your database. But as I understood, you would prefer to use a database itself for this purpose. I am afraid SQL Server does not a have a capability to manage the user's IP address, but I will be glad if I am wrong.
Well if your pages access the database only through an application role, then you could make sure that role doesn't exist on the other databases, so they couldn't see them unless they knew a real user name and password. Make sure sa has a password, so they can't get into things with sa and blank password.
Also talk to your network guy about how he can limit access. Maybe he will have some ideas. We personally always put the outside access databases on different servers than the ones that should be seen from inside. That way no one can get to them through the firewall.
Also talk to your network guy about how he can limit access. Maybe he will have some ideas. We personally always put the outside access databases on different servers than the ones that should be seen from inside. That way no one can get to them through the firewall.
i would recommend if you can have the one that application that exists outside even partially be a completly seperate machine. When you present your argument for it, make sure you mention what would the results be if the network was comprimised as a result of them getting in through this machine. have your network admin help you come up with the justification for having it isolated outside the internal network.
As to the other issue. it depends on the degree to which it gets comprimised. It also depends on what steps you have taken to lock down the machine. Unfortunatly it can be difficutly to fully lock down a machine. You should always plan for the worst case scanario, its comprimised in such a way that they have complete access to the entire machine. As sqlsister said, you can restict access so they could only access that one database based on roles, but if it is comprised far enough it would not matter. It really is best to have anything outside the fierwall completly out and assume it will eventually be comprimised.
As to the other issue. it depends on the degree to which it gets comprimised. It also depends on what steps you have taken to lock down the machine. Unfortunatly it can be difficutly to fully lock down a machine. You should always plan for the worst case scanario, its comprimised in such a way that they have complete access to the entire machine. As sqlsister said, you can restict access so they could only access that one database based on roles, but if it is comprised far enough it would not matter. It really is best to have anything outside the fierwall completly out and assume it will eventually be comprimised.
-
1
- #5
1 - If the DMZ SQL Server is dedicated to SQL, then from Windows make sure only SQL port i open on the machine by using TCP/IP IPSec filtering. More , filter access on the private network servers' outside[exposed to the DMZ] subnet to block everything except SQL port and filter by IP also so that it accepts connections from the DMZ servers.
2 - If the DMZ servers are limited and there is no real benefit or need to run a domain in DMZ then run the servers as standalone servers so that you do not have to open ports needed to support domain functionality. If you ran a DMZ domain anyway, then create IPSec/L2TP tunnels between the web servers and the SQL server using self-signed internal certificates.
3 - "Highly recommended" , make the DMZ domain separate from that of the private network if possible. Use IPSec tunnels between the DMZ SQL server and the private severs.
4 - Use firewalls with packet filtering , stateful inspection and application layer filtering, i.e. MS ISA with the newly released feature pack installed.
5 - With rigor, continually audit the Windows security event logs.
6 - And oh, patch, patch... and remember the latest slammer virus as impetus to be nervous.
7 - Harden the Windows servers using MS guidelines. Sometimes simple measures go a long way, i.e. run only needed services and edit disk ACLs on all machines to be as strict as possible and make sure to remove the dreaded Everyone permissions. Make sure to run SQL service[from control panel] using a limited useid authority with disk ACLs to only the SQL server installation and data directories.
8 - If you can and are ready to move up the ladder, use .NET servers and IIS 6. They are much more secure.
9 - Never, never, read email or the like on the servers or install third party software unless absolutely needed.
10 - Backup data and if, GOD forbid, any server gets hacked or compromised, then re-install the SO and SQL server and never try to clean the server and run with the old installtion.
11 - I am sure I forgot something important, so keep reading and finding ways to improve your security posture..
________________________________________________________________________________
If you do not like change, get out of the IT business...
2 - If the DMZ servers are limited and there is no real benefit or need to run a domain in DMZ then run the servers as standalone servers so that you do not have to open ports needed to support domain functionality. If you ran a DMZ domain anyway, then create IPSec/L2TP tunnels between the web servers and the SQL server using self-signed internal certificates.
3 - "Highly recommended" , make the DMZ domain separate from that of the private network if possible. Use IPSec tunnels between the DMZ SQL server and the private severs.
4 - Use firewalls with packet filtering , stateful inspection and application layer filtering, i.e. MS ISA with the newly released feature pack installed.
5 - With rigor, continually audit the Windows security event logs.
6 - And oh, patch, patch... and remember the latest slammer virus as impetus to be nervous.
7 - Harden the Windows servers using MS guidelines. Sometimes simple measures go a long way, i.e. run only needed services and edit disk ACLs on all machines to be as strict as possible and make sure to remove the dreaded Everyone permissions. Make sure to run SQL service[from control panel] using a limited useid authority with disk ACLs to only the SQL server installation and data directories.
8 - If you can and are ready to move up the ladder, use .NET servers and IIS 6. They are much more secure.
9 - Never, never, read email or the like on the servers or install third party software unless absolutely needed.
10 - Backup data and if, GOD forbid, any server gets hacked or compromised, then re-install the SO and SQL server and never try to clean the server and run with the old installtion.
11 - I am sure I forgot something important, so keep reading and finding ways to improve your security posture..
________________________________________________________________________________
If you do not like change, get out of the IT business...
- Status
Similar threads
