I'd managed to overlook this during the beta cycle, but yesterday I ran across the following statement in the release Exchange 2007 docs:
"An Edge Transport server that is in the perimeter network typically has two network adapters:
A network adapter that connects to the Internet, or external, network.
A network adapter that connects to the corporate, or internal, network."
Don't believe me? Check it out for yourself.
Update 12 Apr 2007: This month's content update removes this assumption from the documentation, so this is no longer the case.
Now, the way this passage is written, it implies to me that the two network interfaces are directly connected to the appropriate networks. That's not the definition of "perimeter network" I'm familiar with; interfaces that reach out of the perimeter tend to conveniently bypass the other layers of security. Your perimeter network (or networks, if you find multiple perimeter networks to your taste) is protected from direct access by firewalls and proxies. Microsoft can't really be advocating a box with one lead stuck into the external network and the other stuck into my interior network, can they?
I could suppose they mean one box with two interfaces in the perimeter network....but no, that just doesn't make sense unless I'm overlooking something. I already expect my Edge server to live in the perimeter, so I've taken the appropriate steps to harden it, including running the Security Configuration Wizard (SCW). Microsoft's recommended SCW configuration gives you instructions on setting up restrictions in the SCW policy to limit which machines can talk to the Edge server on which ports. By it's nature, an Edge server needs to talk SMTP with at a minimum all external mail servers (I'm making the assumption that you're not using a smarthost) and with the Hub Transport servers in the interior network. However, the LDAP connection for the Edge Subscription information only needs to listen to the interior Hub Transport machines. Microsoft's guidance tells you how to configure the SCW policy to achieve this based on network adapter.
I can see some pros to this approach, but the cons are really getting to me. Yeah, it's easier to define policies by adapter, but I can just as easily configure SCW on a single-interface Edge box to lock down Edge Sucscription to the internal network, allow SMTP to all hosts, and prevent everything else -- and by haivng this single interface actually within my perimeter I can enforce these restrictions in my firewall rules, giving me an extra layer of security. In fact, later today I'll describe the ISA rules I used to secure access to the Edge server after hardening it with SCW.
I've tried to think of compelling reasons why I'd hypothetically want dual interfaces on a perimeter machine. I can think of lots of reasons why I wouldn't:
- It increases the level of complexity but doesn't really give me an increase in the security it offers. Not only that, I'm more likely to have to replace an interface when hardware goes bad, than I am going to have to change which subnets everything lives on. In our recent office move, I had a server lose its interface and I had to replace it. Had it been my Edge server, would I have remembered to re-configure the SCW policy to tie it into the new interface? (Would I have needed to? I don't know...and I'd be willing to bet there are very few people out there who can answer that off the top of their head, discounting the guys at Microsoft who worked on the SCW). If my policy is based on network addresses and subnets, as long as I configure the new interface with the same address as the old, my policy is still valid.
- Say I have an attacker go after my Edge server. If this attacker gets into the box, they can shut off the SCW policy and turn on IP forwarding. Boom! Instant egress into my network, bypassing my other controls and layers of security.
- Speaking of layers of security, I being the conscientious admin[1][2] have of course have deployed IPSec filters on my internal network to make sure that my important machines (like my domain controllers and Exchange servers) won't respond to queries initiated from anywhere other than the trusted hosts on my internal network. These filters just got more complicated; now I have an internal IP address I can't trust incoming traffic from....unless I'm an Exchange server and it's SMTP traffic on TCP25.
So, can anyone help me figure out what I am missing, or is this really the bad guidance that it appears to be?
[1] In the hypothetical situation we're describing here.
[2] Ryan and Doug, I can hear you snickering.