Solved

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

Posted on 2006-06-08
30
528 Views
Last Modified: 2008-02-01
This is kind of two questions, the first is, is it best to have an internet web server on our DMZ jioned to our domain or no?  then, what are the steps for setting up ipsec between the database server on the LAN behind the firewall and the web server on the DMZ?  thanks in advance.
0
Comment
Question by:futureman
  • 14
  • 13
  • 3
30 Comments
 
LVL 3

Expert Comment

by:livedrive777
ID: 16865981
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.
0
 

Author Comment

by:futureman
ID: 16866025
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
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16866113
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.

0
 

Author Comment

by:futureman
ID: 16866141
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.  
0
 
LVL 3

Expert Comment

by:livedrive777
ID: 16866148
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?
0
 

Author Comment

by:futureman
ID: 16866163
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.
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16866283
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.
                                   
0
 

Author Comment

by:futureman
ID: 16866470
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?  
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16868435
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.

0
 
LVL 3

Expert Comment

by:livedrive777
ID: 16869826
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.
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16870519
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.

0
 

Author Comment

by:futureman
ID: 16872628
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
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16872678
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.

0
 

Author Comment

by:futureman
ID: 16872869
wierd, i have opened 1433 from the DMZ to the LAN and it still can't see the SQL server.  any ideas?
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16872898
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.
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:futureman
ID: 16873022
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.
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16873253
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.
0
 

Author Comment

by:futureman
ID: 16873275
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>
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16873541
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

0
 
LVL 13

Expert Comment

by:prashsax
ID: 16873648
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).

0
 
LVL 13

Expert Comment

by:prashsax
ID: 16873853
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.
0
 

Author Comment

by:futureman
ID: 16874129
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
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16874187
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
0
 

Author Comment

by:futureman
ID: 16874192
when i run a netstat -an it still doesn't show the ip listening on port 1433.  what am i missing?
0
 
LVL 13

Expert Comment

by:prashsax
ID: 16874207
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.
0
 
LVL 13

Accepted Solution

by:
prashsax earned 125 total points
ID: 16874220
Here is how you can configure SQL to listen on port 1433.

http://msdn2.microsoft.com/en-us/library/ms177440.aspx

Follow it and it will do the trick.
0
 

Author Comment

by:futureman
ID: 16874262
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.
0
 

Author Comment

by:futureman
ID: 16874343
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?
0
 

Author Comment

by:futureman
ID: 16874390
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
0
 

Author Comment

by:futureman
ID: 16874427
one more note, i did have to leave UDP port 1434 open to be able to connect.
0

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Resolve DNS query failed errors for Exchange
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
Viewers will learn how to connect to a wireless network using the network security key. They will also learn how to access the IP address and DNS server for connections that must be done manually. After setting up a router, find the network security…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now