Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 31 replies
  • Subscribers 1 subscriber
  • Views 23341 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

Bypass network security packet filters using web proxy

esev
I've noticed that the web proxy can be used to bypass network security packet filters.  Consider a gateway with three interfaces, one for the WAN, one for the LAN, and one for GUESTS.  If GUESTS are normally not permitted to access web servers on the LAN, but are permitted to access the web proxy (to limit web access), than the GUESTS can make requests through the web proxy to access the LAN.

As a simple measure to prevent this, I've tried using URL Filtering to block hosts on the LAN by URL.  But this won't cut it as anyone can register a domain name that does not match my URL filters and resolves to a host on my LAN.  I've also tried to add network security packet filter rules that block the Astaro LAN IP from accessing any hosts on the LAN - but it seems that the web proxy is exempt from these rules.

What I'd really like is a way to limit the web proxy by destination IP address or IP range.  I know how to do this with Squid (acl to_localnet dst ; http_access deny to_localnet), but is there a way to do this with Astaro?


This thread was automatically locked due to age.
Parents
  • 0
    As I suspected, even in transparent mode, a user can configure their browser to use the proxy non-transparently and get around the packet filters.  I think this is a bug, you shouldn't be able to subvert the packet filter rules by using the proxy.  I've submitted a feature request to add a filter by ip address in the web proxy.

    For now, I've just gone in via the console and added the rules to iptables manually.  I'm wondering what would break if I switched the ordering of the rules on the iptables OUTPUT filter to place the auto-generated rules (that permit the proxy) after the user generated rules.  That way any user-generated deny/drop rules would take precedence over the automatic rules.  I'll wait a bit to see what happens with the feature request.
  • 0 in reply to esev
    Hi esev,
    I am not sure that your example of the dydns registration would work because the 10.x.x.x network is internal and there is no way of relating the internal address to the external address. That would drive a dns insane trying to workout which 10.x.x.x it was really meant to point at.

    Bob, your packet filter rule while limiting the GUESTS to external DNS does not stop them resolving any external advertised servers on the local LAN and being able to come into the ASG from the external interface. I can access my ASG on its external interface from inside by using its dydns entry.

    Ian M

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk
    Hi esev,
    I am not sure that your example of the dydns registration would work because the 10.x.x.x network is internal and there is no way of relating the internal address to the external address. That would drive a dns insane trying to workout which 10.x.x.x it was really meant to point at.


    It'll work.  To test, I registered the example above.  myinternalnetwork.dyndns.org now really does resolve to 10.11.12.100 [:)]
Reply
  • 0 in reply to rfcat_vk
    Hi esev,
    I am not sure that your example of the dydns registration would work because the 10.x.x.x network is internal and there is no way of relating the internal address to the external address. That would drive a dns insane trying to workout which 10.x.x.x it was really meant to point at.


    It'll work.  To test, I registered the example above.  myinternalnetwork.dyndns.org now really does resolve to 10.11.12.100 [:)]
Children
Unfiltered HTML