September 16, 2009 at 8:55 am
We have recently created a new IIS server in our DMZ that will host a web-based conferencing application (Adobe ConnectPro). The application installation will require a SQL Server back end.
I've set this up as follows, and I'd like to hear any suggestions/criticisms about the security of this approach:
- IIS server in DMZ, SQL Server on internal network
- sa login disabled in SQL.
- Single SQL login created through which all communication from IIS server will occur. Login is not a member of any admin role on the server. Login is mapped to a user in just one database needed for the application.
- On firewall separating internal network from DMZ, Port 1433 is opened to IIS Server.
- The SQL server is separate from our main SQL server and was created to hold non-mission-critical application databases, databases that are accessed via the internet, etc.
Are there other steps you'd recommend?
Thanks very much!
Rich
September 24, 2009 at 6:56 pm
Well, I work under the assumption that any IIS box, or box in general, in the DMZ is compromised. Based on that logic, there is an easily accessible path from the outside, through your firewall to a SQL Server. Account might not have access to much, but it is additional surface area for attack.
I would be inclined to hang a SQL Server out in the DMZ, stand alone, Express edition if it is small, and manage connectivity from inside, to it via something like a SOAP proxy. In general, I have a serious aversion to opening 1433 on the firewall even if controlled through ACL's.
September 25, 2009 at 5:11 pm
Hanging the SQL Server in the DMZ brings up other issues, like how to get backup files off, how to patch, etc. so I'd stick with the SQL Server on the internal network. Other things to consider:
- Ensure that the SQL Server service account as well as the SQL Server Agent service account don't have any rights to any other server (except the SQL Server Agent service to be able to write to a file share in order to copy backup files over), especially any of the other SQL Servers inside your network.
- For that matter, ensure that there isn't any service that's running with an account that can access resources anywhere else.
- Make sure SQL Server is at least auditing logon failures.
- Make sure proper security auditing is turned on at the OS level. If you check Microsoft's solution accelerators portion of the Technet site, you'll see the Security Guides for the various OSes and they'll tell you what you need (of course, this should be set via group policy anyway).
K. Brian Kelley
@kbriankelley
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply