Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 2 subscribers
  • Views 12778 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DMZ Hosts can connect to the internal hosts?

jimmyone
Hi all,

how can it be that my DMZ hosts can connect to the Internal Network?

There is no NAT Rule defined for that.
When i try a ping or a telnet to a machine in the internal Network, its successful.

Whats the problem here?
I have looked into the NAT and Packetfilter Rules, there is no visible problem.

Do you have any ideas?

Thenak...

Greetz
Tom


This thread was automatically locked due to age.
Parents
  • 0
    on the top of the pf there should be a deny from the dmz to the internal host
  • 0 in reply to wingman
    When i create a deny Rule:

    Source: DMZ (Network)
    Dest: Internal (Network)
    Action: Drop

    there is no function... I can reach the interal hosts... ??
  • 0 in reply to jimmyone
    deny rule should be the first rule 

    Source: DMZ (Network)
    Dest: Internal (Network)
    Service:All
    Action: Drop 

    Enable the log and to verify it works try to telnet to various ports for the dmz to the internal network
  • 0 in reply to wingman
    Like Wingman says, put it first.  Every set of rules I can think of in the Astaro is processed sequentially.  Once one of the rules is satisfied, the rest are skipped.

    Another "trick" is that routes and rules in proxies and VPNs are evaluated before explicit ones you create.  One of the implications of this is that allowing the DMZ to use the HTTP Proxy means that it can reach your internal network with any allowed service; someone who gains control of a computer in your DMZ has free access to websites in your internal network.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi,

    many thanks to you and sorry...
    You're correct there is no connection possible.

    When i try a telnet from the DMZ Client to any internal Host, there is a Connection abort.

    But i can ping to all internal hosts...
    In my Packetfilter i have all ICMP Forwards and so on unactivated.

    The HTTP Proxy is in use...

    Many Greetings
    Tom
  • 0 in reply to jimmyone
    Tom, what masquerading rules do you have?

    What have you entered in Allowed networks' on the 'Global' tab of 'Web Security >> HTTP/S'?  If your DMZ is allowed, you will want to add blocks on the 'Content Filter' tab for your internal network.  For example, if 'Internal (Network)' is 10.10.10.0/24, add a block for //10.10.10.

    Cheers - Bob
  • 0 in reply to BAlfson
    Tom, what masquerading rules do you have?

    What have you entered in Allowed networks' on the 'Global' tab of 'Web Security >> HTTP/S'?  If your DMZ is allowed, you will want to add blocks on the 'Content Filter' tab for your internal network.  For example, if 'Internal (Network)' is 10.10.10.0/24, add a block for //10.10.10.

    Cheers - Bob


    Bob

    I am able to ping the internal zone and I do have pf rule denying traffic from dmz to internal, I don't have Allow ICMP on/through firewall and I have //192.168.2 under the url blocked as you said. What am I missing?
  • 0 in reply to wingman
    I don't know enough about TCP/IP to understand if the issue with ping is a bug or a feature of ICMP.

    Do you have a packet filter rule like: 'DMZ (Network) -> Any -> Any : Allow' because you want to allow access to the internet?  Unfortunately, that also allows unproxied traffic to your internal network.  If that's the case, create a new Network Definition named "Internet" with 0.0.0.0/0 and bind it to the External interface.  Now, replace the rule with 'DMZ (Network) -> Any -> Internet : Allow', and you can get rid of your 'DMZ (Network) -> Any -> Internal (Network) : Deny' rule.  That will probably leave you still able to ping... let us know!

    Cheers - Bob
Reply
  • 0 in reply to wingman
    I don't know enough about TCP/IP to understand if the issue with ping is a bug or a feature of ICMP.

    Do you have a packet filter rule like: 'DMZ (Network) -> Any -> Any : Allow' because you want to allow access to the internet?  Unfortunately, that also allows unproxied traffic to your internal network.  If that's the case, create a new Network Definition named "Internet" with 0.0.0.0/0 and bind it to the External interface.  Now, replace the rule with 'DMZ (Network) -> Any -> Internet : Allow', and you can get rid of your 'DMZ (Network) -> Any -> Internal (Network) : Deny' rule.  That will probably leave you still able to ping... let us know!

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    I don't know enough about TCP/IP to understand if the issue with ping is a bug or a feature of ICMP.

    Do you have a packet filter rule like: 'DMZ (Network) -> Any -> Any : Allow' because you want to allow access to the internet?  Unfortunately, that also allows unproxied traffic to your internal network.  If that's the case, create a new Network Definition named "Internet" with 0.0.0.0/0 and bind it to the External interface.  Now, replace the rule with 'DMZ (Network) -> Any -> Internet : Allow', and you can get rid of your 'DMZ (Network) -> Any -> Internal (Network) : Deny' rule.  That will probably leave you still able to ping... let us know!

    Cheers - Bob


    just tried removing the dmz ->any->private lan-->deny and add dmz->any-> internet (0.0.0.0/0) but still ping works from DMZ to private lan
  • 0 in reply to wingman
    I meant to eliminate 'DMZ (Network) -> Any -> Any : Allow'
  • 0 in reply to BAlfson
    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
  • 0 in reply to wingman
    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
  • 0 in reply to BAlfson
    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


    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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0: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[:D]0:0a:9a:89
  • 0 in reply to wingman
    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
  • 0 in reply to 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
  • 0 in reply to wingman
    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!
  • 0 in reply to jtarnoff
    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
  • 0 in reply to wingman
    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