DMZ WebServer Issue

[OverSeer]

Here's the situation. I have a webserver out in my DMZ. Nothing strange there but that webserver serves up pages it retrieves from the mail server that's behind the firewall in the private network for the web access function of the mail server. My configuration lets people access the webserver fine and the webserver can retrieve and serve up the pages from the mail server fine but my configuration is less than perfect. If someone were to gain entry into that webserver, they'd have open access into my network. Here's what I have in my config for that part:

access-list DMZ_access_in permit tcp host <web.server.ip.address> any

access-list DMZ_access_in permit tcp host <web.server.ip.address> eq www host <mail.server.ip.address> eq www

If I change that first line at all (like trying to lock it down to only http), I get nothing. The server can no longer access the mail server. What I did do was this:

access-list DMZ_access_in permit tcp host <web.server.ip.address> any eq www

access-list DMZ_access_in permit tcp host <web.server.ip.address> eq www host <mail.server.ip.address> eq www

Any ideas, thoughts or comments would be appreciated for I'm sure there's a better way to do this. Thanks!

*EDIT*: I just did a netstat -an on the mail server and it appears that the webserver is coming through on different ports but it's a range of them. They start at 3176 and proceed to increase by one (3177, 3178, etc.). One session alone (mine) has two "ports" open - 3176 and 3177. Just for the record, the mail server is a Domino server (if that helps at all). Again, thanks for any help!

[a.awan]

It is always better to restrict communication to what is actually required and i know that is exactly what you are trying to do, however, there is one thing i want to point out that unless you have statics configured for other hosts on the inside (to the dmz) anyone compromising your webserver will not be able to initiate communication to those hosts.

I have a feeling that the communication happening between your dmz server and internal mail server is on a destination port different than 80. Turn on logging (debug level - buffered) on the PIX and see what log message appears when you change your access-list. The log should indicate the source and destination ports and should provide us with enough information to proceed.

[OverSeer]

Here is my config if it helps...

[a.awan]

You have the following statement in your configuration:

static (inside,DMZ) 10.1.1.0 100.1.1.0 netmask 255.255.255.0 0 0

Is it a typo as i think it should not read 100.1.1.0 but should be 10.1.1.0 instead?

I would still recommend you do the following after work hours:

pixfirewall(config)# logging on

pixfirewall(config)# logging console (or buffer) debug

Then try altering your access list and see if you get any discard messages in the logs. Post the messages here.

[OverSeer]

1) Yes, that was a typo.

2) Ok. Here's a snapshot of the debug information with both of the access-list lines in.

3) ehirsel: I have to have both of those access-list lines in to get it to work at all...

[a.awan]

I went through the logs and did not see anything out of the ordinary. All communication from dmz to inside seems to be using destination port 80. I asked if you could get the log output of when things are not working. Can you change the access-list to what you are trying to achieve and when connectivity breaks capture the log and post it here?

[OverSeer]

Well. Here are my logs with the following access-list line removed:

access-list DMZ_access_in permit tcp host any eq www

[a.awan]

With this particular line removed i am not surprised that the connection does not work. I am sorry if i am not communicating my requirements correctly but i wanted you to apply the access-list in its end state which is basically:

access-list DMZ_access_in permit tcp host 10.0.0.2 host 10.1.1.18 eq www

Do note that with this access-list bound to the dmz interface your dmz web server will only be able to initiate port 80 connections to 10.1.1.18 and will not be able to initiate any other connections. If other connections are required you need to basically add on to your access-list.

Apply the above mentioned access-list and then get the logs please. Do a clear xlate before gathering the logs.

[OverSeer]

Sorry for the delay in getting this back to you... Here's the results with the change you suggested (I cleared out the useless extraneous stuff from other ip's):

Syslog logging: enabled

Facility: 23

Timestamp logging: enabled

Standby logging: disabled

Console logging: disabled

Monitor logging: disabled

Buffer logging: level debugging, 31 messages logged

Trap logging: level warnings, 3742 messages logged

History logging: disabled

Device ID: disabled

111008: User 'enable_15' executed the 'logging on' command.

302013: Built inbound TCP connection 13143 for outside:68.253.191.118/1359 (68.2

53.191.118/1359) to DMZ:10.0.0.2/80 (web.outside.ip.addr/80)

106001: Inbound TCP connection denied from 10.0.0.2/1208 to 10.1.1.18/80 flags

SYN on interface DMZ

106001: Inbound TCP connection denied from 10.0.0.2/1208 to 10.1.1.18/80 flags

SYN on interface DMZ

[a.awan]

Can you post the exact configuration that was on the PIX when these logs were obtained? It appears that something is denying the connection from your DMZ server to the inside server but from what you have described so far you should not be getting these logs.

[OverSeer]

Actually, I'm not quite sure what caused that problem but it's working now and I've change the line to this. Could you let me know how (un)secure this line is just based off of itself (we'll say they're is no other ACLs)...

access-list DMZ_access_in remark ACL to allow the DMZ webserver to retrieve HTML pages from the Inside mail server

access-list DMZ_access_in permit tcp host 10.0.0.2 host 10.1.1.18 eq www

[a.awan · Accepted solution]

This is exactly the same access-list statement that i suggested putting in and then gathering logs. It is good that things are working for you now.

As far as the security of this statement is concerned well you need to allow this access to make things work. For you there are two layers of security. No outside client directly hits the internal server so that is one layer. Secondly only the DMZ server is allowed to access the internal server via http. In short your require this ACL statement on your DMZ. Just keep your webservers security patches updated.

[OverSeer]

I thank you for all your help (and I never said you never gave me that acl entry :) Just wanted to test other things first)... As for the security, I only have smtp coming in at this time and it's locked down to only coming in from a 3rd party service that we have scanning our email for viruses and blocking spam... Again, thanks for all your help!

[a.awan]

No problem. Glad it all worked out in the end.

[ehirsel]

I assume that this statement allows the web-to-mail server connection to succeed:

access-list DMZ_access_in permit tcp host any eq www

But when you have this statement:

access-list DMZ_access_in permit tcp host eq www host eq www

the server sonnection fails.

The web server will use a random source port gt 1023 because it is initiating a client connection to the mail server since it is acting as a reverse-proxy for its own clients. If you look at the failed acl statement above, you'll notice that you told the pix to see the web server source port as being 80 for the back end connection.

What you need to do is code the acl like this:

access-list DMZ_access_in permit tcp host gt 1023 host eq www

This should be the only line you need in your acl.

Let me know if this works. If it does not, examine the netstat -an command result again and this time, since you are running the command on the mail server, look at the source port. This is the mails server port that accepts the incoming request from the web server.

Let me know if this helps.