The conventional design wisdom, for sensible security, is that _nobody_
should be able to initiate a connection from outside to inside. If
outsiders need to get at something, you put it in the DMZ. Because of how
SMTP works this would prohibit you receiving any email (the sender basically
telnets on port 25 to the receiver), bet that'd make you popular. Sometimes
people open TCP 25 directly to the internal mail-server, but as Walter
pointed out, that leaves you open to other attacks.
The answer here is to open TCP 25 from your MX to an SMTP server (mail
forwarder) in your dmz, open only TCP 25 from this to your Exchange server,
and have this extra box forward all SMTP to your internal Exchange server.
That way if someone breaks into the mail-forwarder they're still not in your
network. This can be just a bare Linux running sendmail (ie free), or if
you use a virus-scanner like MailSweeper you can put it here (make sure it
doesn't paticipate in your internal domain-security).
For Terminal Server, if this is for RAS (ie your own users getting at
internal resources via VPN from the Internet) then putting the TS in the dmz
buys you nothing as the client-TS (or at least client-firewall) channel will
be encrypted and the clients will be authenticated anyway. Plus you then
have to open virtually all ports from the TS box in the dmz to the internal
network (ie nullify the pupose of the dmz). The most reasonable way is to
permit VPN clients (from the Internet) to reach an _internal_ TS. If
however the TS is for external users (maybe providing info to outside
clients) then put it, _and_ all it needs to reach, in the dmz.
The reason for two dmzs is that you don't want networks controlled by others
to have access to any of your servers (even bare utilitarian ones like a
mail-forwarder) without a means to audit the traffic. Put your info
suppliers' routers on one, and your servers on another. Needless to say,
your _real_ servers, the ones your internal clients connect to, always stay
I'm familiar with your situation. An investment bank will just want it
done, NOW. But probably won't see any reason to spend money on security.
Believe me, when you get broken into, it _will be your fault_. I once had a
client who couldn't see any reason to spend 80k to protect 8billion (yes,
that's billion with a 'b'). If whoever controls your budget is not
impressed with the mail argument, use his laptop to dial an ISP, open a
DOS-box, and type 'telnet mail.company.com (your address there) 25', and
watch his face as he gets a command-line on your Exchange server. I've
found it reasonably effective. And mention auditors, he'll always be afraid
HTH. Keep posting if you've got any more questions,
> Hi Walter
> Thanks for responding, I'm breathing easier now. Any thoughts on
> putting the terminal server and the three routers on the same DMZ?
> Also, the Exchange server runs Outlook Web Access, any issues with
> that? thanks again. John
> >:You mendioned needing a 2nd DMZ for providing Internet services.
> >:Well, I'm installing a terminal server and my file and print server is
> >:also an Exchange server using SMTP. Will I have a problem keeping the
> >:Exchange server on the Inside interface? and will I have a problem
> >:putting the terminal server on the same DMZ as the three routers?
> >If the Exchange server communicates with the outside world via SMTP
> >only, then there is no -technical- difficulty in having it on an inside
> >or DMZ interface. If, though, it is a member of a distributed cluster
> >of Exchange servers, especially it is being layered on NT/W2K domain
> >authentication, then it will have fits if you try to NAT it
> >[because the PDCs will try to send the raw addresses to each other
> >in data packets...]
> >Technical problems aside, it is more -secure- to not have any servers
> >on your inside interface. The issue here is that if someone compromises
> >your server (e.g., buffer overflow in Exchange or IIS), then if it
> >is on your inside interface, the attackers gain transitive access
> >to your internal network. It is better if your servers are on a lower
> >security interface (DMZ) and can only respond to requests from your
> >inside network instead of being able to initiate messages to your
> >inside network.