Mr. T says: I pity the fool who runs a web server behind the same firewall protecting his LAN.

I do agree with your point of view and Internal Firewall DMZ is the best. Still, a question came to my mind:

In your example, there is only one access to/from external zone. How would you manage the multiple ISPs, and the fact you have links dedicated to certain services hosted in DMZ ?

Ex: You host web servers in a DMZ at the Internal Firewall, and let’s say a Web proxy for users web access in another DMZ on the same firewall. Web servers have to talk with ISP A, and wou want your users to browse the web through ISP B.

From a routing point of view, you must define the next hop based on the source, so policy based routing, which by experience on screenos and ios is not a valuable solution (side effects and/or difficult to maintain and troubleshoot at a certain point). Or maybe some equipment/firewall can have several routing instance / routing table and DMZs could use different ones ? Or maybe another solution that do not come to my mind ?

Of course, if you use DMZ on your external firewall, the problem is solved, with all the cons of doing this you have described.

Let me know what you think and thanks again for the article.

The article was probably aimed at a logical design level above this but I am struggling to find a best practice guide for IP addressing in DMZs. In the preferred scenario (where the DMZ hangs off the internal firewall), would you give a server a private address range then NAT at the external firewall? For example, a web proxy for internal clients would be hosted in the dmz with a private IP address and then it would be NAT’d outbound?

Thanks,

Duncan

The Juniper NetScreenOS is far superior to ASA and has better routing, easier administration, better performance. However. the NetScreen are being replaced with the new device and you may need to do some research to check it’s what you need. I have been told it’s just as good as NetScreen but I personally can’t say that I know.

You state: “My recommendation is always to use a Cisco ASA as the external firewall and Juniper NetScreen as the internal firewall.”

I’d be interested in knowing why you recommend the above. Is there something inherently better about putting the ASA externally and the NetScreen internally?

I can understand recommending the ASA based on your Cisco background, but why do you recommend the NetScreen? Are there others you have tested?

Also, based on your reply to one of the comments, I get the impression you would have no problem putting an internal VLAN and DMZ VLAN on the same switch. Is this still your position as I didn’t pick up on that in the third Packet Pushers podcast?

Thanks

JR

I disagree, firewalls in my opinion will always be the foremost solution in permiter/DMZ defence. Most of them also include IPS functionality as standard now and as I said above, application inspection. The ASA and Check Point firewalls will both restrict web traffic to RFC compliant HTTP browsing if configured to do so, they are far from being routers that don’t work with some value add.. in my opinion.

I now work for a large network integrator who are a gold/platinum partner across many networking vendors and at present the requirement for firewalls is far outweighing IPS appliances and when IPS is sold it’s often as a firewall software or hardware module. IPS will and is becoming more prevalent but as a complement to a firewall I believe.

Ian

p.s. The site is looking good.

The ASA will perform application inspection and ensure HTTP traffic is RFC compliant.. or have I missed something here?

Ian

While I don’t specifically agree that two firewalls are more secure than one, its a very common idea. The original purpose was to have each firewall controlled by a different team or people. In practice, this doesn’t work.

I believe that the Security Industry has not really grown up and moved on from 1999 when the issue was ‘publicised’. The IEEE clearly identified the problem in its documents and the risk was deemed acceptable. Since Cisco now has features that block VLAN hopping (VACLs, set Default Untagged VLAN, PVLANs etc etc) the risk is easily mitigated.

Exploiting VLANs requires that you compromise a server, elevate or gain root/administrator level access, download and install software and commence VLAN injection attacks. OK, not so hard but requires a high level of competence on the attacker’s part, AND a low level of competence on the administrator’s part.

The underlying problem is that Security People are often inflexible, and unreasonable. The ‘VLAN insecurity’ topic is like fundamental faith issue. I don’t agree with it, and don’t believe that selling separate switches (that are low MTBF, low reliability, low performance, and generally poor operational practice) improves the risk profile. It does shift the risk profile from the Security side to Operational side since multiple switches means more failures. I would always make the point that operational failure is a greater risk than security (your mileage may vary).

Although there are reasons where using individual switches might be a good idea, this would be a truly exceptional corner case, rather than standard best practice.

What is your view on separate physical switches vs vlans for connectivity within the various zones?

Vendor designs will often use separate switches at each zone but, especially with distributed HA firewalls, this can quickly add up to a lot of physical devices with only 2-4 active ports. However given a (correctly configured) outside firewall should it not be safe to assume that the control plane of any (correctly configured) switch behind it should be “secure”? It would therefore be valid to use the same physical switch for outside-failover/inside-failover/internaFWl-ExternalFW connectivity, segmented using vlans?

Effecitvely the FWSM uses the same switch for all functions, but I still read documents stating that seperate switches should be used.

I have read some interesting posts on your blog and would be keen to see your response.

Cheers
Dave

You are right, and I did like the Cyberguard TSP before it got merged into Secure Computing and then merged into McAfee. Lets face it, you aren’t going to buy a proper firewall from McAfee are you. At the moment, firewalls are routers that don’t work with some value add around configuration management, and administrative management.

In the future, security isn’t in firewalls but in IPS and Threat Mitigation Systems. Which, I’m pleased to say, will upset most Firewall people out there today. They may have to learn something…..

I’m not suggesting the front-end firewall be removed entirely, but that it is not used to terminate inbound sessions.

/John H

First, I’m a fun of your schema

The DMZ place in your schema has, in my opinion, some advantages :
1- If you have a heavy Ext DMZ traffic you may prefer to not overload the internal firewall with such noisy traffic.
2- The DMZ servers are subject of security threats, If one of them is hacked, I suppose the external firewall is not doing the job correctly, then it’s a good idea that the internal firewall handls DMZ Internal traffic.

Have a nice day