My internetworking needs are simple. People inside want web access and to send outgoing mail. People outside want to send mail inside, view our web site, and some authorized ones do VPN.

So what public services should I web-publish/server publish, and what should I put on the perimeter network or DMZ?

Does anyone have any criteria for deciding, guidelines?

I tried setting up a DMZ. At first, I tried private addressing in the DMZ. This is possible to do if you exclude the addresses in the LAT. However, you cannot publish servers that are not in the LAT. Therefore, you can only route to these servers and do packet filtering and protocol rules. This makes the private addressing a challenge and is no doubt why most DMZ's are publicly addressed.

I am moving away from a publicly-addressed DMZ with back-to-back firewalls to a tri-homed model. Rather I still have the back to back, but I am thinking of moving the DMZ behind both and onto a third interface of the second firewall.

One alternative I tried configuring tonight is to use the third interface on the ISA server with a different privately addressed subnet that is in the LAT. This means using server and web publishing rather than a publicly addressed DMZ. However, it puts these servers which do public services (web site, inbound SMTP, public DNS, etc) on a different subnet which ISA can control (because it's the router). I can use packet filters, protocol rules, IPSec and so on to protect my main private subnet from this subnet where my published servers are.

Does anyone have an opinion? When is it better to use publishing, and when is it better to use a public DMZ?

As you know, the point of a DMZ is to create a separate security zone. Typically, the setup of putting public resources on another internal network segment won't do this, but you can do it with filtering and IPSec. If you are doing this, then you have configured a separate security zone and you're in good shape.

The big problem with the trihomed DMZ config is the single point of failure and the single point of attack. If the single ISA Server fails, then you're in bad shape. With the back to back config, they have to move through two layer to get to the internal network.

However, if you are using a screening router of some sort, then you have your back to back config with multiple vendors: the best way to go.

HTH,
Tom

------------------
http://www.isaserver.org/shinder/



Get It Here!

I came up with a rule of thumb kind of policy to analyze whether something should be published or perimetered. This is "what services or ports need to be provided to the public" and "what services and ports does the server need to have inside."

If the server needs to have a lot of public accessibility, and doesn't need to get anything from inside, it should go on the perimeter network (DMZ). Examples would be public DNS, autonomous HTTP-web servers, or some kind of system where a lot of ports are open for public access.

If the server needs very limited public accessibility, but needs to have a lot of access to the private network, it may be better to publish it. Tom Shinder mentioned something like this in a reply to another message.

A good example of this is the VPN gateway where you provide VPN so that a remote site or user has all the access they'd get if they were in the office. Another good example I have is a Domino server that contains databases. The databases themselves are what I'm trying to protect, yet people want access to them from anywhere on the web without a Notes or VPN client. If you haven't seen "iNotes" check it out - it's very cool webmail.

There's no reason to put this on the DMZ because there's nothing else to protect from it. I've been able to publish the Domino http server, bridge it to SSL on ISA, and serve it up in the lab. I may try to get my passthru server to serve it up and then publish the passthru server with SSL bridging. That means the server I'd publish wouldn't have the databases on there, just a passthru connection to the server that does. This would make it a sort of passthru-then-proxy with SSL solution, or "double-proxy."

Notes passthru is supposed to be fairly secure since it uses a PKI and good encryption. Now I just need to secure the SSL with something better than a server certificate and user password auth. I've got client-certs on smartcards done in the lab, but people think this is too geeky or too paranoid. SecureID doesn't require readers like smartcards, but I've seen SecureID defeated by "racing." Using a keystroke recorder, you can get the string as the user types it in - and race them for the last character of the OTP. Certs are better, but now I'm getting off track.

I guess the third possible scenario would be services that need to be highly accessible to the public and have a lot of access to inside. I guess this scenario just defeats normal security conventions altogether, but maybe application-layer security features or EFS can handle it.

The tri-homed model splits ISA to create a "virtual" back-to-back model. The front firewall just does packet filtering and so on, while the back firewall does SecureNAT etc. With the true back-to-back ISA/ISA model, you don't have to split the features of ISA, but there's some question as to the extra benefit you get for doing double-NAT or what not.

For now, I decided to work with an ISA-published, privately-addressed subnet behind multi-vendor back-to-back firewalls, instead of a public DMZ. Since I did this, I also realized that instead of using ISA and RRAS security features (packet filters and IPSec) to protect my private network from the published servers on this subnet which I'm calling an "ante-net," why not use the much more powerful router I've got on my switch's policy feature card? This runs an R5000 processor and is effectively the same as a Cisco 7200 router. Now I can apply packet filtering, IPSec, policing, and more all on a much more robust platform than the Windows box that runs ISA.

This makes a router-ISA-router back-to-back-to-back configuration. This might sound needlessly paranoid, but considering the robustness of the router and L3 switching for wirespeed policy-application, two of the three layers should be virtually transparent to throughput.

I'm just glad I get to play with this stuff.

Good points. However, the trihomed set, while perhaps 'virtually' like a back to back setup, doesn't work that way in implementation at all!

With an actual back to back setup, you have the option to use public or private addresses. With the trihomed setup, you must use public addresses.

HTH,
Tom

------------------
http://www.isaserver.org/shinder/



Get It Here!

Other than "translating" the public ip to the internal ip does publishing provide any greater security than simple packet filtering provided on a DMZ? I'd assume intrusion detection works for both?

What about performance? Is translating "slower" than running a DMZ with packet filtering, or is it sixes?

Thanks for the input.

Chris

I created 2 separate INTERNAL subnets (192.168.0.0 & 10.0.0.0), both in the LAT. I used one for the users and the other for the servers, and then published all of my servers with ISA. This way I was able to publish my servers and let my users use all the necessary services but still maintaining my "DMZ" untrusted on a different IP segment controlled by ISA.

An important issue to remember is that the DMZ is untrusted, since it is accessible from the internet. Therefore, a communication should NEVER initiate from DMZ into the internal (users) segment. If this happens, you have probably been hacked, so make sure you got your filters set.

My 2 cents
Maurice

You can use an internal segment for your DMZ, as long as the packets are filtered. You can use IPSec Policies on the servers on the DMZ to prevent servers on the DMZ from initiating communications to any of the trusted network. You would have to do this if the segments are both directly connected to the ISA Server.

However, its better to connect the internal interface of the ISA Server to a network segment that is connected to a router, and then let the router's packet filters control access between the trusted and untrusted networks. This is the easiest way to do it, and you don't have to require that the ISA Server perform LAN routing duties (the ISA Server will be busy enough doing what its supposed to be doing).

HTH,
Tom

------------------
http://www.isaserver.org/shinder/



Get It Here!

is it possible to contact me. I would like some more information on your setup with the Domino server. I'm facing the same here.

Thanks in advance,

Brian

btimp@dtz.nl