Security Policies - your opinion...

[diago]

This may sounds like a newbie kind of question but I''d like some general feedback on it anyways.

1. How do others limit access from their external DMZs to their private networks?

Take database access for example. Do you maintain a policy that says the web and database should be on the same server, do you allow for example SQL access from your external DMZ to your private network? Do you have a seperate DMZ that specifically houses the SQL database servers from the web servers. This last option makes the most sence to me.

Another example would be backups. How are people backing up their servers in their DMZs - do you allow your internal backup server to initiate an inbound connection into the DMZ?

2. With regards to limiting private network access to the DMZs how far do you go?

We have admins at my work who rely on RDPing to servers in our DMZs. I argue the point that we already have DELL KVM modules and that they don't need RDP. What are people's thoughts on allowing connections to be initiated from a particular private VLAN into DMZs? What security issues arise from doing so?

Where can I find general information on security policies such as this?

[RayPesek]

That isn't a newbie question. It's a fully loaded political and religious question rolled into one! :-)

The rule I use is that everything on a single DMZ (or VLAN) should have about the same risk. You don't want a high-value item (database) on the same segment as a low-value item (web server). If the web server gets hacked and it's got the database on it, it's game over.

Always assume the attacker can get root/admin on a server. You can simulate this by sitting at its keyboard and monitor and running a bunch of tools. Anything you can access on the internal network, a hacker can access as well. Do not assume that rules with IP address limits will work. As an admin attacker, if I change the server IP to .3 from .2, or add a second IP address of .3 while leaving .2 alone, can I bypass your rules?

With intelligent firewalls that understand traffic and do not blindly think everything on 1433 must be SQL, I don't think it's a big risk to have the database on the internal network as long as the traffic between the web server and the database runs through an intelligent firewall. In fact, this is how Microsoft's ISA system works with its "server publishing" rules.

What are you gaining by putting the database on its own DMZ? Won't it have to talk to the internal network for anything? If so, how is the data going to get there from here?

Internal-to-DMZ must be locked down as tight as possible. Can you use the KVM's while remote? If not, then RDP would make sense as long as you're giving them static IP's and using rules to limit RDP to just them (at a minimum).

My DMZ servers are primarily front-end or standalone boxes. I image them periodically for disaster recovery but they don't contain any real volatile data.

ALWAYS assume that if someone paints a target on your company's back, they are going to get in. Always. They have a lot more time and they only have to succeed once. Your job is to throw enough hurdles in their way that they will be noticed before they can get all the way in.

Ray

[diago]

Thanks RayPesek - your feedbacks appreciated.

By creating a functional DMZ to place the SQL databases I was thinking they'd be much more secure than being housed internally. They will only be used by webservers in the external web DMZ and as such I can lock the traffic down to only accept MS-SQL from the web DMZ, and as you say the packet inspection obviously will help by checking the service flowing over the port is in-fact MS-SQL.

Our DELL KVMs are all network aware and hence we are able to remote into them.

At this stage I'm not really having technical problems with firewalls - its the policy and topology issues that I'm constantly battleing with. I want to follow best practise so if anyone has any recommended reading I'd appreciate the reference.

If anyone else has some comments on this please keep them coming.