DMZ Hosts can connect to the internal hosts? - Page 2

BAlfson · #11 (**permalink**) 05-21-2009, 09:43 PM

I meant to eliminate 'DMZ (Network) -> Any -> Any : Allow'

wingman · #12 (**permalink**) 05-27-2009, 07:28 PM

I am still facing the same issue. what's strange though is that despite the top deny rule that drops all traffic from dmz to internal network, i can still telnet to port 80 (from DMZ to internal network)

I think that exactly the situation you have described on your earlier post. Is there a way to fix that?

PS I've followed the instructions with no luck

BAlfson · #13 (**permalink**) 05-27-2009, 09:37 PM

Do you have the HTTP Proxy in transparent mode? That might account for that behavior with telnet on port 80 if you don't have blocks set in Anti-Spam.

I'm curious, did the "Internet" definition trick stop the pings to the internal network from the DMZ?

Cheers - Bob

wingman · #14 (**permalink**) 05-27-2009, 10:01 PM

yes the operational is set to transparent mode (not full transparent). I've tried telnet from DMZ to port 21 and 80 and both are allowed. The strange thing is that I can the see the pf log and the traffic is set to block (when trying random ports). Ping is still allowed when I set //192.168.2 under the blocked list (I can untick the Allow ICMP through firewall option and DMZ is unable to ping internal zone but internal zone is able to ping DMZ!)

however, port 80 and port 21 are still allowed if i telnet from DMZ to internal zone

Code:

21:56:18	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:56:21	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:56:27	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:56:51	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:56:54	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:57:00	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:57:19	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:57:21	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000

21:57:28	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000
len=111	ttl=110	tos=0x00	srcmac=00:00:00:00:00:00	dstmac=00:b0:c2:02:e3:c7
21:57:40	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:57:43	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:57:49	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:58:00	Packetfilter rule #1	TCP	
172.16.1.2	:	52454
→	
192.168.2.31	:	8080
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89

BAlfson · #15 (**permalink**) 05-27-2009, 10:48 PM

Quote:

however, port 80 and port 21 are still allowed if i telnet from DMZ to internal zone

Interesting. Maybe you could try adding a logged packet filter rule at the top: 'DMZ -> HTTP -> Internal (Network) : Allow' and see if the port 80 traffic is being accepted before the PF rules. If the traffic doesn't show up in the PF log, then that would be proof that it's being captured by the proxy as I suspect. I would guess than any service can be used by telnet if it's in 'Allowed target services' on the 'Advanced' tab of 'Web Security >> HTTP/S Proxy'.

I'm not sure why the block is allowing the traffic. What happens in the Content Filter (HTTP) log?

Cheers - Bob

wingman · #16 (**permalink**) 05-28-2009, 07:59 AM

Quote:

Originally Posted by BAlfson

Interesting. Maybe you could try adding a logged packet filter rule at the top: 'DMZ -> HTTP -> Internal (Network) : Allow' and see if the port 80 traffic is being accepted before the PF rules. If the traffic doesn't show up in the PF log, then that would be proof that it's being captured by the proxy as I suspect. I would guess than any service can be used by telnet if it's in 'Allowed target services' on the 'Advanced' tab of 'Web Security >> HTTP/S Proxy'.

I'm not sure why the block is allowing the traffic. What happens in the Content Filter (HTTP) log?

Cheers - Bob

JUst to add to my previous port. I am also able to telnet to port 8080 and 3128 (I have a pf rule that allows Private_Lan -->web surfing-->any allow). WEb surfing ports are : 8080,3128,443 (port 80 is only set to http proxy)

Haven't tried out your suggested action yet Bob.I am planning to do it during the weekend

jtarnoff · #17 (**permalink**) 06-09-2009, 10:20 PM

I just setup a DMZ for a ShoreTel VPN Concentrator yesterday, and I'm having the exact same issue where it seems that the device on the DMZ can contact hosts on the LAN, even though I have setup the first Packet Filter rule to drop all traffic from the DMZ to the Internal network.

I have tried it both with and without HTTP security/proxying turned on, and traffic still seems to be allowed, despite the rule.

Conversely, I have tried setting up a rule to block traffic FROM the Internal LAN to the DMZ, and that works fine.

Anyone have a solution yet?

Thanks!

wingman · #18 (**permalink**) 06-09-2009, 10:28 PM

I am currently trying different configurations to solve that issue. I will post when I find a solution

Even though I don't have any rule that allows web traffic from DMZ to private lan it still goes through. I don;t have DMZ on the allowes hosts of HTTP/S

it's strange :s

BAlfson · #19 (**permalink**) 06-10-2009, 03:37 PM

Jtarnoff, did you put the blocking rule at the top of your list of packet filter rules? Remember that, like most everything in the Astaro, PF rules are processed sequentially, and the rest are skipped when the traffic pattern is matched.

One thing is certain, and that is that this is not an Astaro bug; this must be an unintended consequence of some conguration item.

If you have a logged block or alllow rule at the top and see no application of the rule in the PF log, then you have proof that the traffic is being allowed by automatic packet filter rules in a proxy or NAT. If it does appear in the log, then you know that one of the following PF rules is allowing the traffic.

Cheers - Bob

wingman · #20 (**permalink**) 06-11-2009, 09:22 PM

I have the blocking (traffic from DMZ to Internal Zone is rejected not Dropped) rule on the top to block all traffic from DMZ to private Lan. All traffic is blocked (tried telnet via random ports). However telnet on port 80 is still allowed but traffic is not logged on the pf.

Telneting on port 8080,3128 is blocked by the pf but telnet works :s

Code:

21:18:04	Packetfilter rule #1	TCP	
172.16.1.2	:	49767
→	
192.168.2.31	:	3128
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:18:07	Packetfilter rule #1	TCP	
172.16.1.2	:	49767
→	
192.168.2.31	:	3128
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f:d0:0a:9a:89
21:18:13	Packetfilter rule #1	TCP	
172.16.1.2	:	49767
→	
192.168.2.31	:	3128
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:

The only possible solution for this traffic to be allowed is via HTTP proxy (However I believe there is an issue since port 8080 and 3128 are still allowed despite the fact that pf blocks them!!)

On the HTTP proxy I have blocked URL : \\192.168.2.31 (the destination for the telnet test) but the traffic still is permit.

Can someone confirm in which way does Astaro checks the traffic? (ie first HTTP Proxy then pf etc)