Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 29 subscribers
  • Views 8606 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

Understanding Local Service ACL

shred

I'm trying to understand Local Service ACLs - what do they actually do? Are they simply opening ports for a specified zone? That's what I initially thought but after some testing, I'm confused.

For example, if I'm using Sophos XG as my DNS server and I uncheck DNS from my LAN Local Service ACL, I can no longer resolve any host names. Why is this the case if the Local Service ACL is simply enabling ports for a zone? If I'm in the same zone and subnet as my Sophos XG DNS, shouldn't I be able to still access the DNS server? However, when I have a separate DNS server set (Pi-hole) and my DHCP server setup appropriately, I can resolve hostnames just fine with the DNS Local Service ACL unchecked. This makes sense to me since the Pi-hole server is in the same zone and same subnet.

Another example is if I uncheck User Portal from LAN Local Service ACL, I can no longer access the user portal web UI. Again, same question applies to above. I'm trying to access these services (DNS and user portal web UI) from within the same zone and subnet.

Anyways, any help would be appreciated. Just trying to understand Sophos XG better. I really think we need the ability to see all firewall rules (system generated) so we truly know what's going on with the Sophos XG. I've already submitted an idea request for this here about 9 months ago. Who knows if it will ever be implemented but more votes would help I suppose.

https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/32511967-display-hidden-firewall-rules-on-the-firewall-pa



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

    Just to add this: ACLs are destination based firewall rules for the services, which XG offers. So basically everything which tries to reach a specific services of the XG. 

    The Point behind those ACLs is, to get rid of the X firewall policies and instead "have a decent overview of your current who can do what". 

    Most scenarios, the ACL´s are enough - means they are easy to setup (just tick it) and are easy to use. I am more likely using ACL´s instead of firewall rules, because i can setup them faster. 

    *edit* 

    As far as i know, there are plans to give the customer a better solution for ACL´s. But i do not have any ETA. 

     

    *edit²*

    Maybe you can post a KBA request on the new section for a KBA published? 

    community.sophos.com/.../knowledge-base-article-suggestions

  • 0 in reply to LuCar Toni

    Thanks for the replies. That makes a little more sense, they are outbound/destination based firewall rules to services offered/hosted by Sophos XG. But this is the part I guess I don’t understand is how it’s blocking something that’s in the same subnet/zone/interface. Is it using some sort of application filtering? I think how it’s implemented could be okay if there was better documentation and more transparency in what it’s actually doing. I’ll suggest a KB article but honestly I’ve found KB articles not the most helpful as they don’t provide the level of detail you really need to understand how Sophos XG works. It could just be me though as I can’t just understand what something does but need to know how it actually works to have the ability to setup things correctly/smartly.

    KB request created:

  • 0 in reply to shred

    "But this is the part I guess I don’t understand is how it’s blocking something that’s in the same subnet/zone/interface. Is it using some sort of application filtering?"

    Can you explain this in more detail? I do not understand, what you mean? 

    ACL´s basically allow just something. If no ACL applies, the "default drop" will apply. 

    It is a destination ACL - means the interface IP will apply to the ACL. 

     

  • +1 in reply to LuCar Toni

    My network skills aren't expert but i think there are two cases that can help:

    A) if you have a windows server on a connected switch with the windows DNS server feature on the same zone/network/interface then that traffic isn't really going to be controlled by a firewall rule. Correct me if I'm wrong but the switch would handle the packets.

    B) in sophos XG case where it is providing DNS instead, access to that CAN be controlled even within that same zone/network/interface BECAUSE the traffic has to go to and from the XG interface directly. That's where the local ACL can do a bit more, simply, in a simple one-screen way.

  • +1 in reply to apalm123

    Yeah, that’s exactly what I’m getting at and that makes sense. My understanding is Sophos XG (or any firewall) doesn’t control packets within the same subnet and zone because those packets never go through Sophos XG (like @apalm123 mentioned, are just handled by the switch). But that makes sense if Local Service ACLs are blocking packets with a destination TO Sophos XG, it can block based on the fact it’s trying to access a service on the Sophos XG device by simply blocking access to the interface IP and port.

    So I guess an example would be if I uncheck DNS for LAN, it’s blocking port 53 UDP to a destination IP of 172.16.16.16 (my Sophos XG interface IP address). This is why when I am using Sophos XG as my DNS server, websites won’t resolve as expected because those packets have to go through Sophos XG. But when I use another device on my network as the DNS server (Pi-hole at 172.16.16.15), it works because of what was mentioned above. Even if I was able to somehow create an outbound rule and tried to block 172.16.16.15, it wouldn’t work because those packets never pass through the firewall (same subnet).

    I’m assuming Local Service ACL are basically floating firewall rules (pfSense or OPNsense terms) that apply to outbound traffic with a destination set to the Sophos XG interface IP.

Reply
  • +1 in reply to apalm123

    Yeah, that’s exactly what I’m getting at and that makes sense. My understanding is Sophos XG (or any firewall) doesn’t control packets within the same subnet and zone because those packets never go through Sophos XG (like @apalm123 mentioned, are just handled by the switch). But that makes sense if Local Service ACLs are blocking packets with a destination TO Sophos XG, it can block based on the fact it’s trying to access a service on the Sophos XG device by simply blocking access to the interface IP and port.

    So I guess an example would be if I uncheck DNS for LAN, it’s blocking port 53 UDP to a destination IP of 172.16.16.16 (my Sophos XG interface IP address). This is why when I am using Sophos XG as my DNS server, websites won’t resolve as expected because those packets have to go through Sophos XG. But when I use another device on my network as the DNS server (Pi-hole at 172.16.16.15), it works because of what was mentioned above. Even if I was able to somehow create an outbound rule and tried to block 172.16.16.15, it wouldn’t work because those packets never pass through the firewall (same subnet).

    I’m assuming Local Service ACL are basically floating firewall rules (pfSense or OPNsense terms) that apply to outbound traffic with a destination set to the Sophos XG interface IP.

Children
  • +1 in reply to shred

    Those ACLs works only for traffic going to the Interface IP of XG. 

    So basically it is to handle the services, which the XG provides. If you use a DNS server within your network or outside your network is not handled by the ACLs. And this is the point, where you should take a look. In Case of "something has to go through XG", you have to design an firewall policy. In Case of you want to use something of the XG, you have to use the ACL´s. As simple as this it is. 

    You can basically run an XG without activate anything on ACL. 

    Best fact is SSH / Webadmin. You active the ACL for LAN, so Webadmin is reachable for the XG LAN IP. 

    ACL´s simply enable the packet filter for the service of XG as a simple way. It is more simple to "just tick" something then build an firewall policy for everything. 

    Even on UTM9 i rarely take a look at the "system based firewall rules". 

  • +1 in reply to LuCar Toni

    Hello LuCar Toni,

    We have been trying to understand what the 'Wireless Protection' local service blocks. We assumed it would block SSID's and or WiFi associations from occurring on an interface if the box was ticked. All we have to test with is a Sophos XG 105w. Ticking or unticking the box for wireless protection for any interface doesn't seem to impact the laptops from seeing SSID's, associating & authenticating to the WiFi network.

    The million dollar question is whether this protection is only applicable when using external Sophos WAPs? Secondly, what process / protocol / or RF function of a wireless request is it designed to block?

    If this is not the correct way to address this issue please point me in the proper direction. Thanks for any assistance with this in advance.

     

    SteveG