Thread Info
  • State Verified Answer
  • Replies 5 replies
  • Subscribers 3 subscribers
  • Views 2730 views
  • Users 0 members are here
Options
Suggested

Does the QUIC protocol have to be added as a service for 'Block QUIC protocol' to work?

shred

Edit: Think I figured it out. I believe some of the weird log entires I was seeing was based on some some devices using QUIC while I was enabling/disabling things.

Short answer, yes, UDP 443 must be added to the 'Service' section of the firewall rule for the 'Block QUIC protocol' option to work. I think it would be worthwhile to have a check in place to see if UDP 443 (or 'Any') exists in the 'Service' section when this option is enabled. Recommendations in my second post below.

 

The simple answer to the question in the title appears to be no, but I'm noticing something interesting with 'Block QUIC protocol' and having the QUIC service (UDP 443) added to a firewall rule 'Service' versus not having it added. What appears to be happening is:

- If I have a firewall rule with 'Block QUIC protocol' enabled but I do not have the QUIC service (UDP 443) added to the firewall rule 'Service' section, when a client attempts to use the QUIC service, it will block as expected but then continue to traverse down the firewall rules list until it can find a firewall rule that will allow it or be blocked by the default DROP ALL rule. This is expected behavior.

- Same scenario as above except if I do have the QUIC service (UDP 443) added to the firewall rule 'Service' section and a client attempts to use the QUIC service, it still appears to still block as expected but it seems to stop there (i.e. it doesn't continue to traverse down the firewall rules list).

 

Here's a simplified version of my setup and how I'm seeing this:

- Firewall Rule #1: A basic LAN to WAN rule (basically the default that gets created) except the 'Source networks and devices' are a list of MAC hosts and the 'Services' is a list of services that these clients use (e.g. HTTP, HTTPS, IMAP, NTP, etc.). Block QUIC protocol is enabled. Logging is disabled.

- Firewall Rule #2: This is also a basic LAN to WAN rule except unlike the above rule, 'Source network and devices' and 'Services' are set to Any. Block QUIC protocol is enabled. Logging is enabled. The idea behind this rule is to log/catch any services that I don't have set in Firewall Rule #1.

When a client attempts to use the QUIC service, I see it being blocked in the firewall rule by Firewall Rule #2 which is what one would except in the first scenario I mentioned above. Firewall Rule #1 is blocking QUIC so it continues to look at the next firewall rule which is still blocking it but logging is enabled.

Now if I add the QUIC service to Firewall Rule #1 and a client attempts to use the QUIC service, I don't see any logging at all. This is what I don't quite understand.

Parents
  • +1

    Hi Shred,

    I'm confident that the QUIC protocol is only blocked as part of that checkbox when 443/udp is allowed as part of the allowed services list. But i can't remember if it is an application identity block or a straight block on 443/udp.

    The reason why you're not seeing anything blocked on FW rule #1 i assume because your logging is still diasabled?

    The advisory is not very informative on how the v17.5 block works:

    Emile

  • +1 in reply to Emile Belcourt

    I think I kind of figured it out. First off, you're absolutely right that you must have the QUIC service (UDP 443 and 80) included in the 'Services' portion of the firewall rule in order for the 'Block QUIC protocol' option to work. My recommendation for the Sophos team would be:

    1. Add a QUIC host service by default for UDP 443 and 80. Currently users have to create their own (unless I'm just completely missing it - I've looked multiple times).
    2. When 'Block QUIC protocol' is selected, if the QUIC service is not included in the 'Services' section of the firewall rule, there should be a prompt that lets the user know they need to add the QUIC service, exactly like when you click 'Scan IMAP' for example under 'Scan email content'. One caveat is that if 'Services' is set to 'Any', it should not prompt the user for obvious reasons (currently happens with the scan email content options). Additionally, if a user subsequently removes the QUIC (or Any) service with 'Block QUIC protocol' still enabled, it should prompt the user that those features will not work properly.
    3. Update "Advisory: Google's QUIC protocol bypasses scanning on Sophos XG Firewall" with the same information mentioned in the above paragraph.

     

    Now, here's where my confusion comes from. Here's the scenario (similar to my original post):

    - Firewall Rule #1: A basic LAN to WAN rule (basically the default that gets created) except the 'Source networks and devices' are a list of MAC hosts and the 'Services' is a list of services that these clients use (e.g. HTTP, HTTPS, IMAP, NTP, QUIC, etc.). Block QUIC protocol is enabled. Logging is disabled.

    - Firewall Rule #2: This is also a basic LAN to WAN rule except unlike the above rule, 'Source network and devices' and 'Services' are set to Any. Block QUIC protocol is enabled. Logging is enabled. The idea behind this rule is to log/catch any services that I don't have set in Firewall Rule #1.

    In this scenario, when a client attempted to use QUIC, I see nothing in the logs even though it should be blocked and logging is enabled on Firewall Rule #2. With QUIC being blocked in Firewall Rule #1, it moves to the next firewall rule (#2) at which point it's also blocked but logging is enabled so I'd expect it to appear in the logs.

    Take the same scenario above but now change Firewall Rule #2 to have 'Block QUIC protocol' disabled. Now what I see in my logs is QUIC being allowed to pass which makes sense based on what was explained above. What doesn't make sense is:

    1. Why does this show up in the logs but not when 'Block QUIC protocol' is enabled for Firewall Rule #2?
    2. Why does the log entry show that the connection attempt is allowed to pass but listed as Firewall Rule #1? Remember, Firewall Rule #2 is what allowed it to pass and it was blocked by Firewall Rule #1.

    ---

    Sophos XG guides for home users: https://shred086.wordpress.com/

  • 0 in reply to shred

    Hi Shred,

    Tbh, if you don't have a service that includes 443/udp then that checkbox or off is irrelevant.

    Additionally, how will Sophos represent in the GUI on a firewall rule configuration that is set to accept, say any, services the putting the quic service as block via the services section when the checkbox represents that fine.

    Also, you still have logging disabled on FW #1 so nothing would show up for the blocking of QUIC on FW #2 because it is blocked on FW #1. In your original scenario you didn't have QUIC as a service so it would not have been picked up as a match condition as matching service. Yes this does make that checkbox irrelevant if you turn it on when you don't have a match of 443/udp in the service list but then this falls back to a non issue. It's not permitted as part of the match condition so the block would never apply but it was never allowed on that FW rule in the first place. It then got caught by FW #2 as you had 443/udp as a matching service.

    The match condition occurs before the block checkbox is applied. To "square the circle" would be to grey out that checkbox if the firewall rule physically does not match 443/udp but that's extra logic and is wastefully unnecessary.

    Hope that makes sense.

    Emile

Reply
  • 0 in reply to shred

    Hi Shred,

    Tbh, if you don't have a service that includes 443/udp then that checkbox or off is irrelevant.

    Additionally, how will Sophos represent in the GUI on a firewall rule configuration that is set to accept, say any, services the putting the quic service as block via the services section when the checkbox represents that fine.

    Also, you still have logging disabled on FW #1 so nothing would show up for the blocking of QUIC on FW #2 because it is blocked on FW #1. In your original scenario you didn't have QUIC as a service so it would not have been picked up as a match condition as matching service. Yes this does make that checkbox irrelevant if you turn it on when you don't have a match of 443/udp in the service list but then this falls back to a non issue. It's not permitted as part of the match condition so the block would never apply but it was never allowed on that FW rule in the first place. It then got caught by FW #2 as you had 443/udp as a matching service.

    The match condition occurs before the block checkbox is applied. To "square the circle" would be to grey out that checkbox if the firewall rule physically does not match 443/udp but that's extra logic and is wastefully unnecessary.

    Hope that makes sense.

    Emile

Children
  • 0 in reply to Emile Belcourt

    Unknown said:

    Tbh, if you don't have a service that includes 443/udp then that checkbox or off is irrelevant.

    Yeah, that makes sense. If traffic isn't matching the firewall rule, then nothing on that firewall rule applies.

    Unknown said:

     

    Additionally, how will Sophos represent in the GUI on a firewall rule configuration that is set to accept, say any, services the putting the quic service as block via the services section when the checkbox represents that fine.

    I'm not entirely understanding this sentence. Are you saying it wouldn't make sense to add QUIC as a service to the 'Services' section when you check the 'Block QUIC protocol' because it's sort of redundant? I could see that, but I personally like consistency in UI designs and firewalls that are "transparent" in the sense it still shows what's going on "behind the scenes". If it was designed as such, I think the mail scanning options should then follow the same design principle.

    Unknown said:

    Also, you still have logging disabled on FW #1 so nothing would show up for the blocking of QUIC on FW #2 because it is blocked on FW #1. In your original scenario you didn't have QUIC as a service so it would not have been picked up as a match condition as matching service. Yes this does make that checkbox irrelevant if you turn it on when you don't have a match of 443/udp in the service list but then this falls back to a non issue. It's not permitted as part of the match condition so the block would never apply but it was never allowed on that FW rule in the first place. It then got caught by FW #2 as you had 443/udp as a matching service.

    The match condition occurs before the block checkbox is applied. To "square the circle" would be to grey out that checkbox if the firewall rule physically does not match 443/udp but that's extra logic and is wastefully unnecessary.

    This might just be misunderstanding on my part but to me, it would make sense that if a firewall rule is performing any action on some traffic/connection, it should show up in the logs if logging is enabled. I understand FW #1 in my example was blocking QUIC, but since it's going to look at the next firewall rule (#2) and it's being blocked with logging enabled, logically I would think it should show up in FW #2's logs because FW #2 performed some action on that traffic and logging is enabled.

    ---

    Sophos XG guides for home users: https://shred086.wordpress.com/

  • 0 in reply to shred

    Hm, so it appears if it is blocked by Firewall Rule #1 (using my examples above), it doesn't move to Firewall Rule #2. That would explain some of the confusion with the logs. For some reason I thought it was in fact moving to the next firewall rule after being blocked but I just tested it multiple times and that's not the case. I think some of the one offs I was seeing in my logs was perhaps from changing settings while one of the devices on my network was utilizing QUIC.

    So, that answers that. My only suggestion would be what I mentioned above in regards to prompting the user when 'Block QUIC protocol' is selected.

    ---

    Sophos XG guides for home users: https://shred086.wordpress.com/

Unfiltered HTML