Should a Web server on DMZ be joined to Domain to use IPSEC?

Well, in any scenario where you have something in the DMZ that requires domain authentication this issue becomes convoluted.  The best solution in my opinion is to use something like an application firewall like Microsoft ISA server.  The way this works is your ISA server goes in your DMZ and the web server goes on your LAN with your database server.  The ISA server is what clients are accessing via port 80 or 443 and it is proxying traffic to the web server on the LAN, but doing stateful packet inspection of all of the traffic.  The way the firewall rules then work is port 80 and 443 are open going into your DMZ from the internet, port 80 and 43 are open from your ISA server to your web server, and obviously the web server can talk openly to the DB since it is on the LAN.  Kind of similar to how the CSG works in a Citrix deployment with a DMZ.

To answer the question about what has to be open if you do place your web server in the DMZ:  You would pretty much need to open all ports (or at least all higher ports and then a select number of ports like for RPC) to your domain controllers for authentication and then whatever ports for DB connectivity directed to your DB server (lilke 1433 for SQL).  Since the domain controllers are doing the auth you don't have to open additional ports to the DB server.

I like the ISA server idea but i don't have one right now.  Regarding the web server, can i just leave it as a stand alone server on the DMZ and still set up IPSEC between it and the DB server behind the firewall?  i have it set up to use a pre-shared key but i haven't been able to get it to connect.

One more thing about the ISA set you described, is it a security issue to have the web server on the domain and behind the firewall?  what if it is compromised?  what kind of procedures would you recommend to prevent this?

thanks again
Futureman

Yes, you can have a standalone WEB server in DMZ and still have IPSec between Web server and Database server.

Its generally a good idea to keep Web server in DMZ, so that if its compromised, no one can come inside your LAN. Since you will open only few ports to your LAN from DMZ.

It you open all ports between DMZ and LAN, then the whole point of having the DMZ is lost.

Why do you want to have IPSec between Webserver and Database.

Are they using some public network to communicate with each other.

To create an IPSec between then, you need to open port 500/UDP for ESP.
Once this is done, all the ports are automatically open between DB and WEB server, because all the IP traffic will now travel in UDP packets on port 500.

This way you cannot control the ports opened between Web server and Database Servers.

I hope, you understand what I am trying to explain here.

Regarding your comment on why i want to use ipsec - well i guess I am not sure it's necessary but here is what i was thinking.  Because the web server is on the DMZ and it has a public IP and the DB server is behind my firewall on the LAN, i assume that when the web server interacts with the DB server through the firewall that it exposes the DB connection to the internet since the web server has a public IP.  Am i wrong?  Because it's on the DMZ is it not possible for the data between the DMZ and the LAN to be compromised?  It would sure be easier to not have to worry about setting up encryption between the two but I have read some articles and it seemed like that's what they were suggesting.  

I agree that it is not a good idea to have the web server on your LAN typically, but in the ISA config this is suppose to be an exception.  The goal of ISA server itself is that since it is doing application level inspection that someone would have to compromise the ISA server in order to be able to compromise the web server.  This would be the same concept as someone compromising your web server and thusly being able to compromise your DB server with exploits known for the DB platform.  It is simply a more limited risk b/c the ports opened are minimal and the ISA server adds that additional layer of application security for your web server.

I don't recomend opening up ports from the web server into the LAN any more than needed obviously.

If you are having trouble getting IPSec to work from your DMZ into your LAN it could be a result of NAT.  If I recall correctly IPSec traffic doesn't allow you to NAT it b/c it breaks the communication.  Could that be part of your issue so far?

Also is the reason you want IPSec for domain authentication or something like that?

well i don't actually need domain authentication - i was just thinking that i might need the web server on the domain to set up IPsec but that doesn't seem to be the case.  my main concern is protecting the traffic from the web server to the DB server and from the DB server to the web server.  so if it doesn't need to be encrypted if its on the DMZ then i am good but I wanted to get some feedback on that idea.

I am confused.

If you are creating a DMZ, then how would your webserver have a public IP address.
DMZ is a third zone other than Internet and LAN.
You do not give Public IP address to the servers in DMZ, instead you NAT the connection from Internet to DMZ, and that too on specific ports.

Here is how it looks like.
                                  DMZ                      
                                    |
Internet----------------|Firewall|-------------LAN

DMZ is not exposed to Internet, their exist a firewall between it and Internet.
We create DMZ for publically accessible server to provide extra layer of security
Since, these server are publically accessible they are more prone of break in.
What DMZ does is that it create a seperation between LAN and vulnerable server.
So, even if your DMZ server is compromised, your LAN is still safe.

Setting up IPSec between DMZ web server and LAN db server will save your data should anybody tries to sniff the packets going from DMZ to LAN.

If you create a IPSec Policy for web server and DB server,
1) You wont be able to filter traffic based on ports on firewall.(After IPSec even firewall cannot read the packets. It will just allow all packets to pass to DB).
2) Should Web server is compromised, the attacker will have access to all ports on DB server, as their is not port filtering happening on firewall.

As, for NAT being problem for IPSEC, just use ESP mode instead of AH, and it will traverse any kind of natting as long as packet reaches the peer.
                                   

i have my DMZ running in standard mode so it uses a routable IP but i have rules set up to only allow traffic on ports 80 and 443 to the DMZ.  So you are saying if I set  the DMZ in NAT mode, then I should be able to communicate with the DB server on the LAN without fear of anyone sniffing my connection?  

Ideally you keep your DMZ behind firewall and do natting on firewall only and not router.

How many interfaces you have in your firewall.

If you have only two interfaces, then you have no choice but to keep your server like this only.

And your IPSec idea was relevant.

One correction from my side, You can control the ports you want to implement IPSec. So you can go ahead and create a IPSec policy for port 1433 to SQL DB.

OK, now I understand more about your issue.  In response to one of the above comments:  No you do NOT NEED to use private addresses in your DMZ.  Many, many, many people use public addresses in the DMZ to avoid issues with split DNS, etc...  it is very common.  It does not compromise your security in any way since you are still using access lists to restrict traffic to/from hosts in the DMZ.

Now as to whether or not you need IPSec to encrypt traffic from your web server to your DB server:  In my opinion the answer is no i don't think it is neccesary.  The two reasons I would use for this are as follows:
1) The DMZ is still behind your firewall and should not be open to the internet enough so that sniffing traffic should be an issue.  Now that is just my opinion.
2) It seems to me that you may end up having to punch holes in your firewall to allow for IPSec communication that wouldn't be there otherwise.  This may not be a huge concern, but if there really is no risk of sniffing traffic it is at the very least an unneccesary exercise.

Yes, you can keep your Server with Public IP, but it is more secure to keep it with a private IP address.

As for IPSec, you can set it up, and is more relevant should you have any other server in your DMZ.

As for having to open a port for IPSec, then you won't have to open any port for SQL.
All traffic will pass thru UDP/500 only.

But, as I've said earlier, no one create IPSec between their server in DMZ and LAN.

IPSec is only required when data is travelling over public network.

ok, so i set up the web server to go to the sql server and i opened the ports on my firewall for it to talk to the sql behind the firewall but it will not connect.  i have verified that i can create connections to the sql server from the LAN but not the DMZ.  which ports should be opened from the DMZ to the LAN to allow a web app to talk to a SQL Express 2005 DB?
thanks again
Futureman

The default TCP port for SQL Server 2005 Express is 1433.

The SQL Server Browser listens on UDP port 1434.

You only need to open 1433/TCP for your Web server to work.

wierd, i have opened 1433 from the DMZ to the LAN and it still can't see the SQL server.  any ideas?

use this command on your SQL server.

netstat -n -a | find ":1433"

This will show you if SQL is listening on this port.

It is possible that your SQL is configured to some custom port or its is working on NEtbios only.

I ran this netstat -n -a | find ":1433" and it didn't do anything.  I have other datasources set up to connect to the SQl server using the exact config i am using on the web server on the DMZ.  they are all using port 1433.  I have a rule on my firewall to allow traffic on port 1433.

use

netstat -n -a  

this should show you a list of ports.
Try and locate port 1433 and its state should be listening.

If you can't find it, paste it here.

Here is what i get - not showing 1433?
Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    0.0.0.0:21             0.0.0.0:0              LISTENING
  TCP    0.0.0.0:25             0.0.0.0:0              LISTENING
  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING
  TCP    0.0.0.0:119            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:554            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:563            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1043           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1048           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1054           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1070           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1075           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1079           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1755           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:2522           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:2761           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:2920           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4434           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:7999           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:9920           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:9950           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:9960           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:10000          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:19995          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:19996          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:46972          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:51011          0.0.0.0:0              LISTENING
  TCP    10.2.0.16:139          0.0.0.0:0              LISTENING
  TCP    10.2.0.16:445          10.2.0.38:4194         ESTABLISHED
  TCP    10.2.0.16:445          10.2.0.59:1497         ESTABLISHED
  TCP    10.2.0.16:1051         10.2.0.19:389          ESTABLISHED
  TCP    10.2.0.16:2761         10.2.0.22:3239         TIME_WAIT
  TCP    10.2.0.16:2761         10.2.0.22:3244         TIME_WAIT
  TCP    10.2.0.16:3389         10.2.0.59:2648         ESTABLISHED
  TCP    10.2.0.16:4103         66.151.158.177:8200    ESTABLISHED
  TCP    10.2.0.16:4172         10.2.0.19:389          CLOSE_WAIT
  TCP    10.2.0.16:4379         10.2.0.22:1139         ESTABLISHED
  TCP    10.2.0.16:4573         10.2.0.19:135          ESTABLISHED
  TCP    10.2.0.16:4574         10.2.0.19:1026         ESTABLISHED
  TCP    127.0.0.1:1066         127.0.0.1:9950         ESTABLISHED
  TCP    127.0.0.1:1106         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:4563         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4564         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:4565         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4566         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:4567         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4568         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:4569         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4570         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:4571         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4572         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:4577         127.0.0.1:9920         TIME_WAIT
  TCP    127.0.0.1:4578         127.0.0.1:9960         TIME_WAIT
  TCP    127.0.0.1:9950         127.0.0.1:1066         ESTABLISHED
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:500            *:*
  UDP    0.0.0.0:1025           *:*
  UDP    0.0.0.0:1026           *:*
  UDP    0.0.0.0:1434           *:*
  UDP    0.0.0.0:1755           *:*
  UDP    0.0.0.0:3456           *:*
  UDP    0.0.0.0:4000           *:*
  UDP    0.0.0.0:4500           *:*
  UDP    10.2.0.16:123          *:*
  UDP    10.2.0.16:137          *:*
  UDP    10.2.0.16:138          *:*
  UDP    127.0.0.1:123          *:*
  UDP    127.0.0.1:1027         *:*
  UDP    127.0.0.1:1039         *:*
  UDP    127.0.0.1:1094         *:*
  UDP    127.0.0.1:3188         *:*
  UDP    127.0.0.1:3217         *:*
  UDP    127.0.0.1:3232         *:*
  UDP    127.0.0.1:3456         *:*

C:\Documents and Settings\areiadmin>

Yup, its not their.

Either your SQL is not listening on any TCP port or its a custom port.

This is very common. SQL working on NETBIOS only.

Just to be surem could you use fport.

It is a utility which will map all these ports to the actual program which is using it. It you could not find it in fport as well then you SQL is surely not working on TCP/IP, but only on NETBIOS.

http://www.foundstone.com/resources/termsofuse.htm?file=fport.zip

This is how you can check in SQL Server as well.

1. Open the Microsoft SQL Server Enterprise Manager.
2. Right-click on your server instance (you may have to expand the server groups).
    Choose Properties.
3. Under the General tab, click the button labeled "Network Configuration". The SQL Server Network Utility will be      
    displayed.
4. On the right, under the Enabled Protocols, you should see TCP/IP. Select it and hit the Properties button.
   The Network Protocol Default Value Setup dialog will ask for the Default Port for SQL Server (it will most likely be  
   1433).

Here is the explanation for what you are facing.

Dynamic port allocation
 In the dynamic port allocation process, when you start the instance of SQL Server for the first time, the port is set to zero (0). Therefore, SQL Server requests a free port number from the operating system. As soon as a port number is allocated to SQL Server, SQL Server starts listening on the allocated port.

When an instance of SQL Server uses dynamic port allocation, the connection string that is built at the SQL Server client does not specify the destination TCP/IP port unless the user or the programmer explicitly specifies the port. Therefore, the SQL Server client library queries the server computer on UDP port 1434 to collect the information about the destination instance of SQL Server. When SQL Server returns the information, the SQL Server client library sends the data to the appropriate instance of SQL Server.

If UDP port 1434 is disabled, the SQL Server client cannot dynamically determine the port of the named instance of SQL Server. Therefore, the SQL Server client may not be able to connect to the named instance of SQL Server.

this thing is killin me.  What you said makes sense. So i opened up UPD 1434 on the firewall, and I went into SQL and removed the dynamic IP and set it to 1433.  Still nothing.  I tired fport and it says i need to be an admin to run it, i am logged in as an admin

Locate this key on SQL server.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>\MSSQLServer\SuperSocketNetLib\Tcp\IPAll

Notice the TCPDynamicPorts value and the TCPPort value. These values appear as follows, depending on your port allocation method:

TCPDynamicPorts = Current port used
TCPPort = Current port used

when i run a netstat -an it still doesn't show the ip listening on port 1433.  what am i missing?

Its because you SQL is not listening on this port.

Its using dynamic port allocation.

Check the registry path, port is listed in key TCPPort.

This is the port on which your SQL is running.

prashsax, thanks for all your help - that worked, i got the port set and was able to get the connection up and running.  I really appreciate it.

one more question - It just connected and now it won't connect again.  i had replication set up from my other SQL server and I see that it is connected on 1433 now, would that be keeping me from connectinig again from my DMZ web server?

nevermind, i found out what i did, i had a second ip on the web server and the rule i set up was just for the other ip, i'm good now

one more note, i did have to leave UDP port 1434 open to be able to connect.