Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 26 replies
  • Subscribers 29 subscribers
  • Views 5312 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

Allow specific URLs but block non-URL 443 traffic

JasP

I want to allow a PC to access specific web sites and nothing else. I have setup a firewall rule on XG 18 that allows HHTP/S services and set a web policy.

What happens if a program tries to make a direct connection from that PC to another computer on those ports? Won't that be allowed by the allowed services? How do you stop this from happening so only the allowed URLs will pass?

I've read loads of posts about web filtering but can't find the answer.



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

    Hello JasP,

    So you only want to allow for example https://thiswebsite.com and nothing else?

    If you have Web Policy with the specific URLs applied then the XG shouldn't allow access to any other website or connection. Additionally, you could create a Firewall rule below this one and block port 443. 

    Regards,

  • 0 in reply to emmosophos

    If you have Web Policy with the specific URLs applied then the XG shouldn't allow access to any other website or connection.

    This doesn't appear to be correct.

    I spent some time testing this. I created a rule at the top of the firewall for one server that allowed HTTP and HTTPS and had a web policy that allowed access to one URL. I then created a rule just below it that blocked all other traffic from that server. I then used a utility called Packet Sender running on my test server to send and receive traffic to another external server running Packet Sender and they could send traffic backwards and forwards on ports 80 and 443 without being blocked. What was even more disconcerting was that, despite having logging turned on for both rules, the traffic didn't appear in the firewall log at all!

    My rules are below:

  • 0 in reply to JasP

    Hi,

    you will need to tick the web proxy box and select your web profile before your block test will work. You also might need to tick block QUIC.

    ian

  • 0 in reply to rfcat_vk

    When you say web profile, do you mean web policy? As you can see in my screenshots, I already have a web policy selected and have block QUIC selected.

    Changing to web proxy instead of DPI makes no difference. I can still connect to other servers directly over 443 and 80.

    The only positive is that the traffic is now showing in the firewall log (logged against the correct rule so it isn't being allowed by another rule).

  • 0 in reply to JasP

    Hello JasP,

    Thank you for the follow-up!

    I will need to double-check on this, and get back to you! Allow me a couple of days!

    Regards,

  • 0 in reply to JasP

    Sorry for the confusion, I was using the iPad and the screen is a little small for seeing the extra details in your screenshots.

    Please add a screenshot of your web policy.

    Ian

Reply Children
  • 0 in reply to rfcat_vk

    Web Policy screenshots below. Kept it simple for testing.

  • 0 in reply to JasP

    Hi,

    cludflare dns does not use https as far as I know, so that test should fail, you would need a real URL.

    ian

  • 0 in reply to rfcat_vk

    I just picked an existing policy to use in the test. It doesn't really matter for the purposes of this test as I am not checking URL blocking, I'm checking what happens to non-URL, direct connections over port 80 and 443.

    FWIW Cloudflare offer both DNS over HTTPS and DNS over TLS and if you try https://cloudflare-dns.com/ in a browser you will see it does resolve to a web page.

  • 0 in reply to JasP

    Hi Jasp,

    I might be getting a bit old and grey, I understand DSN usingTLS, but to use a URL to lookup a DNS requires a DNS in the first place, fails the pub test very badly.

    Anyway have yo u looked at this page on the XG.

     

    Ian

  • 0 in reply to rfcat_vk

    We're all getting old and grey! Software that does DNS over HTTPS tends to have two approaches. Either it allows an IP rather than a URL or it has 'fallback' port 53 DNS settings that allow it to resolve the URL before switching to DNS over HTTPS.

    I have had a look at the page you indicated but I already have the most secure settings set.

  • 0 in reply to JasP

    I would suggest you try a different URL, that doesn't change the access mode during your testing.

    Blocking specific sites and allowing specific sites does work, you do need to examine web policies and default settings. Also you might need IPS to get classification etc. and add an application setting of block al in your test allow rule.

    Ian

  • 0 in reply to rfcat_vk

    For the purpose of this test, the web policy is immaterial, it's just a simple, single URL policy that I put in the firewall rule so I had a policy there. The test server isn't doing DNS at all so there is no change of access mode. I could put any web policy in there it wouldn't make a difference to what I'm testing. The original server that I found this problem on actually uses a different web policy.

    rfcat_vk said:
    Blocking specific sites and allowing specific sites does work

    It does if you're accessing URLs. I've tested it multiple times and tested it again on the test server. I can open a browser and access https://cloudflare-dns.com/ fine and can't access any other web sites. But the rules I posted do not block direct access to any IP on HTTP/S ports. If you just want to allow access to specific URLs and nothing else, this does not work and potentially is a very big problem.

    I did look at App Control in the firewall rule but is was no help. I'd already tried an app setting of 'Block All'. This had the effect of stopping direct IP access but it also prevented the permitted URLs from working. I briefly looked at having an app control that allowed just the application I wanted but it hasn't been detected (been running this XG with IPS for a couple of months now) and there is no way to add your own application definitions.

    Having a firewall rule that allows access to specific URLs and nothing else is a common requirement and my current configuration doesn't achieve that and I've yet to see a solution that does. I'm particularly interested in what Emmanuel comes back with as he seems to think that what I have done should work. He may be mistaken and I'm missing something or their is a bug in the implementation of URL filtering with big security implications.

  • 0 in reply to JasP

    Hi Jasp,
    you are doing something wrong. I have a number of rules that provide access to specific urls for specific devices.

    ian

  • 0 in reply to rfcat_vk

    rfcat_vk said:

    Hi Jasp,
    you are doing something wrong. I have a number of rules that provide access to specific urls for specific devices.

    ian

    That part works for me too (URL permit/block isn't the issue). But have you tested whether those rules also allow a direct IP connection (not via a URL) to unwanted IPs? I suggest you try it because you might get a nasty shock! You can do a quick dirty test by trying to open a telnet session on port 443 to the IP of a known web server. You won't get anything in the telnet window but if it connects then you are seeing the same issue as I am. I went further and used a utility running both on my local server and a remote server to pass test messages between the two.

    Since I started using XG (from the first v18 beta) I have wondered about this question of direct connections. I had guessed that if you set a web policy that the rule would only allow those URLs and nothing else because that is what made sense from a firewall point of view. I've been really busy so only just got around to asking the question here to confirm my understanding is correct and actually testing it myself. It is not working as I expected!

  • 0 in reply to JasP

    Hi Jasp,

    no telnet on macOS, so I setup a firewall rule that allowed https to34.215.119.153

    Connection to 34.215.119.153 port 443 [tcp/https] succeeded!

    But, I don't have any blocks for IP addresses in my active policies.

    I will add block IP to the active policy and update this post.

    Ian

    Update:- no affect on 80 or 443. The worst thing is it seems to bring back memories of an issues I raised many years ago, but cannot remember the answer. So something wrong with the proxy reading the format of a supplied IP address. Somebody dropped the ball in programming and inQA testing it would seem to me.