Web Server on a DMZ and Active Directory

[moconnor]

This is a two sided question part philosophical part technical.

If I have a new Win 2k3 web server that I put on my DMZ is it foolish to allow it to join my AD Domain by opening up the proper ports for AD communication between the DMZ interface and the inside interface?

Or is that just going against smart firewalling? Can an attacker cross from outside intf to DMZ to inside intf?

If it is a wise thing to do, how do I do it? I assume just open the ports that MS uses like 135,137, netbios,139 and 445(did I forget any?). Is there anything that I am missing?

Thanks for any advice either philosophical or technical.

Marc

[mostiguy]

you would need to open tons of ports. probably those, 88 for kerberos, etc. its messy.

windows stuff does not play well with dmz's. if you are stuck on the dmz idea, make it a standalone server

[moconnor]

Thanks mosti.

OK, after reading a bit more about the application that will run on this web server in the DMZ I found out that it uses AD authentication and will need to make calls to a SQL Server database(SQL Server is port 1440 I think). It will need to be accessed by web users and internal corporate users.

What do I do now? Open all those nasty MS ports and SQL server ports and hope for the best? Is it even safe?

[mostiguy · Accepted solution]

I would probably put it on the inside. In this day and age of viruses, worms, spyware, p2p apps, etc, your users are often (while general not as malicious) as dangerous as the outside world. Using a DMZ for MS products is darn near impossible, unless it is for limited filtering (blocking users access to SNMP, terminal servicies and other fixed management ports) in an otherwise default permit stance (as opposed to the general firewall best practice of default deny, and selectively permit).

Because of the need for relative openness between MS servers and clients, I have a fairly aggressive hardening, patching and antivirus policy.

If you want to try to put in in your DMZ, you need to determine how your internal users would access it. If they are accessing it via the http interface as well, that is good (some apps have both web interfaces as well as fat binary client packages that use different ports, occasionally dynamic). You could then selective allow access from the sql ip address to the AD servers only, and open up things a ton there. Still, there is the risk that if that box got compromised it could be a conduit to the other hosts. Because this MS stuff is such a headache to DMZ, I generally recommend people think about hardening servers instead of trying to force the square DMZ peg into a round hole.

For IIS, look are the IISlockdown utility, which is an add on for win2k/nt4, and might be included out of the box on win2k3. It is menu driven, and can help you disable stuff you don't need. Hacking Win2k exposed is a great book to pick up. The NSA.gov has security guidelines for most MSFT server products.

[moconnor]

As always you have nailed the question.

After plowing through my Cisco documentation last night the work alone to get it up on the DMZ is crazy. I will never understand why it needs to be that difficult with MS products.

So I guess I will harden, harden, and harden that server and join it to the domain. What do you suggest for the outside world getting in, just a static and an access-list using port 80 only? Will that effect my internal clients internet surfing at all?

Marc

[genghiskhan]

I find your post interesting due the fact that our Network Manager wanted to put a M$ Win2k file server running IIS on the dmz. This server is a part of the internal windows domain. The idea is to provide access to all files residing on the server to off site users and internal users.

My recommendation was not to do this, and instead use a vpn to provide access from offsite. No takers on this idea.

Initially, I opened up every port from offsite to the server, since he did not know the ports needed for this to work. He did give me a 3 page printout of the ports that M$ uses for comminication. There are about 100 various ports both tcp and udp. By running a traffic capture on the offsite link while accessing the server, I was able to narrow it down to just http traffic to offsite users.

Also, I opened up everything to the inside from the dmz to the domain controller. Then I had to open up everything to all inside hosts for access to the server via network neighborhood, and for mapping a drive to the network shares.

This was all done with barely any time for testing, due to his making promises for the live date in some pointed hair boss meeting before testing was completed.

Now, it will be more difficult to close off ports, since it is in production mode.

So, if you are determined to see this thru, you need to be sure that it is well tested before going live.

If you do the traffic capture, you will need to capture traffic going both ways in order to see the whole picture of the M$ communication mess.

I hope this helps in your quest. Just make sure that the server is hardened to the core, and all unneeded services are shutdown. I guess this is possible with a M$ OS.

G'Day,

Rpger

[mostiguy]

for client web surfing, you should not need to do anything. since the pix is stateful, and it allows all connections from higher security ints to lower by default, so long as your nat and global/static commands are correct, people should be able to browse, etc freely.

[patrick.cannon]

For microsoft products through firewalls on technet:

(sql-msdtc)

q250367

q178517

q183293

q306843

q119493

You have to change rpc to use static ports instead of dynamic above 1024.

[moconnor]

Patrick,

Great 'q' articles. It sounds as if you have done what I am trying to before, if so did it work? Any pointers.

Cheers,

Marc