Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 27 subscribers
  • Views 13363 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

Disallow all http/https traffic except through the proxy?

mark57165

I'm trying to figure out the best way to prevent all http/https traffic from going through the firewall except if it's going through the proxy.  This way I can be sure all http/https traffic, regardless of port, is filtered.  I have the proxy working fine, I'm just looking for the firewall rule(s) that I need.



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    you will need to workout which protocols you are allowing through the proxy and add them to your proxy rule and then follow that by a firewall rule that blocks/drops/rejects all other protocols.

    You will need to think this through very throughly because of your mail, ftp and maybe remote access. Also what is your company policy on facebook, twitter etc?

    Ian

  • 0 in reply to rfcat_vk

    As for policy, I’m strictly logging right now aside from some of the obvious security-related stuff.

    My question is this: it appears that the web proxy follows the firewall rules. So if I allow a host into the web proxy and then block it from going outbound, would the web proxy follow that rule? I clearly need to do more testing on this.

  • 0 in reply to rfcat_vk

    Here's the problem: When I block HTTP and SSL, it blocks it even though the web proxy.  I want to block it only if a client attempts to use those directly.

     

    Again, here's what I'm trying to accomplish here:  I want all HTTP/HTTPS traffic blocked unless it is through the web proxy, and I want to do it using deep packet inspection so I don't have to worry about users bypassing it on non-standard ports.

  • 0 in reply to mark57165

    Rule at the top is setup for proxy using the proxy configuration you have set in your login script. Your proxy rule has scan http/s enabled so the users also need a certificate installed otherwise no packet inspection and no internet access.

    Next rule bocks http/s and you also tick block non standard ssl.

    Ian

  • 0 in reply to rfcat_vk

    Can you give me an example of the top rule for this? I'm not sure how to identify that a user is using the proxy.

  • 0 in reply to mark57165

    Hi Mark,

    this is one my my firewall rules. It is not the top one because I mail, ntp, dns and VoIP rules above it. Although it is the top rule for general access.

    Ian

  • 0 in reply to rfcat_vk

    Got it.  So you're allowing HTTP and HTTPS by port.  I don't want to do this... I want to use the application filter to block all HTTP and SSL connections unless they're going through the web proxy.  When I attempt this, the web proxy seems to follow the top rule and blocks access too.  That's the behavior I'm trying to avoid.

  • 0 in reply to mark57165

    Hi Mark,

    https and ssl are not applications but protocols that used by applications. To use the direct proxy you will need to ensure that the use devices are configured for port 3128 only for web access. All my testing tells me that http/s go through the the transparent proxy function, not the standard proxy which you are trying to use.

    You will need some sort of proxy pac to configure your users when they are on your network.

    Ian

  • 0 in reply to rfcat_vk

    Right. I have a proxy pac and it’s working correctly. But again, in a firewall rule, how do I differentiate between users accessing the web through the proxy versus users accessing the web directly?

  • 0 in reply to mark57165

    I was just experimenting with my mac by putting in the XG proxy and failed every connection, that is a side issue.

    Those that don't use the proxy configuration you setup a rule at the top.

    source LAN, network any, destination wan, network any, services http/s choose the rule type to drop or reject which is ever your choice.

    Ian

  • 0 in reply to rfcat_vk

    So a couple of things here. First, I do not want to block by service.  I thought I had been clear on that. When you block by service, it only blocks by TCP port and can be easily bypassed.  I want to block using deep packet inspection so HTTP and HTTPS are blocked no matter what the destination port is.

    Second, when I add a firewall rule to apply to anyone that isn't using the proxy, it also applies to people using the proxy.  How do I determine, in a firewall rule, that a user is going through the web proxy?

  • 0 in reply to mark57165
    You need to add udp for https in the list. Blocking by deep packet inspection requires you to install a certificate on every device and then setup application lists you want to block. At this stage I am not aware of how you differentiate a proxy user from a firewall user. I tried the proxy user setup and there is a rule I cannot identify that blocks all proxy traffic even with the firewall rule I have in place. Flosupport would you please provide some assistance with the thread. Thank you Ian
Reply
  • 0 in reply to mark57165
    You need to add udp for https in the list. Blocking by deep packet inspection requires you to install a certificate on every device and then setup application lists you want to block. At this stage I am not aware of how you differentiate a proxy user from a firewall user. I tried the proxy user setup and there is a rule I cannot identify that blocks all proxy traffic even with the firewall rule I have in place. Flosupport would you please provide some assistance with the thread. Thank you Ian
Children
  • 0 in reply to rfcat_vk

    Yup.  I have DPI working and HTTPS scanning working on the clients I'm testing on with the CA certificate from the device.  OK.  I'll keep messing around and if/when I find an answer, I'll post it here for reference.

    Once I gain more experience with this thing, if I discover that it truly seems impossible, I'll add a suggestion in the other forum.