I do not understand how XG's Application Control work in detail (under the hood). Are any documentation somewhere?
I have to control and restrict some Traffic between LAN and Production due to written regulation of security.
e.g. for understanding
In this example we have to Block HTTP on Port 25.
How can I solve this with Sophos XG?
So what you want to do is L7 aware Policy, with protocol enforcement.
You want to open port 80, but only if It's HTTP traffic, or port 25 if It's only SMTP? Or port 53 if It's only DNS?…
XG applies Rules based on the common criteria: Source IP, destination IP, service (Port).
Everything is a session, so every connection is a session and XG applies a filter rule on this "session".
So if you create a rule for service HTTP and HTTPs you can allow or deny certain Apps, which uses HTTP/s.
You could use a ANY Services rule, and deny certain applications.
You would have to figure out the application, which you do not want to have, and block this app on your Rule for Port 25. Or the simple way is, only to allow the application SMTP and deny all other apps.
To be honest, this is the old scenario, where you are allowing based on TCP/IP and are scared, bad people using the Port 25 for other traffic, like HTTP. There are multiple problems with this view. First of all, SMTP should not be open for everybody. Only for your designed Mail server (Nobody should be able to send spam with your IP). Second of all, HTTP is "dead". Bad people uses TLS over XX (They basically find a open port and use TLS to encrypt the traffic). So DPI engine comes handy to find this kind of traffic on every port.
Just some thoughts about this.
I had the same thoughts like you.
In my opinion, however, this is extremely unsatisfactory. Why, let me explain.
1st) We open outgoing all Ports.2nd) Then we look into a session and try to filter out some traffic.
Why is this suboptimal? The session is established, and it is possible that the appfilter rule does not detect this traffic.In this case the traffic runs through the firewall.
What we need is a strict combination with Appfilter and traditional L3 Session and a bypass rule in Sophos' Appfilter system.
This give us back the control of the full traffic.
This means: IP Source and IP Destination and destination Port and L7-Application -> Allow / Deny
This would be great.
I've sent you a message with more information. (I'm trying to find all posts about this.)
Thank you, I've read that Postings.
BTW: I worked the last years with PaloAlto...
Unbelivable what Sophos ignores in 2020 ....
rfcat_vk said:Then you can further enhance enforcement by enabling block non http traffic on http ports etc.
Could you please explain to me how to enforce protocols over Sophos XG ?
I'm on v18 MR 2, all rules are using DPI Engine instead of the old Web Proxy. (No, I'm not going to use the old Web Proxy, it creates more headache than fixes.)
I've created a Rule that allows only HTTP from a host to another host, and blocks everything else.
But I'm able to connect with SSH without any issues over port 80.
It even detects the traffic as SSH...
There are many things to talk about. I guess, we cannot cover everything in this post. But there is a difference between Application Control and Application protection. The problem nowadays with "Attacks" is, those guys like to use normal applications and use TLS encryption to communicate. Therefore you can start to block the application Chrome, but they will simply use your browser to build a channel back. (Its more complicated than that - always recommend https://nakedsecurity.sophos.com/ )
You can build many real L7 scenarios with XG, as the firewall backend allows such processes. But there are certain limitation like groups etc.
For example, you could simple build LAN to WAN, allow and Deny apps, you want / do not want. That will work perfectly fine on all Ports and all apps.
Another example is group support. You could build a firewall rule User A LAN to WAN, allow all apps. User B Lan to WAN, only Browser allowed.
It gets complicated, if you want to allow per user different Apps and deny other.
From my understanding, a control product is to "allow" unwanted things. A "protect" product is to deny attacks etc. You can allow or deny pornographic content. Is it harmful? Likely not, but not wanted in most businesses. Do you want to stop the ransomware to lateral movement? Yes i want to. But thats likely a IPS and DPI topic rather than a application control.
Attacks are complex and uses different mechanism to spread. Look at tools to white hack for example. They can literally inject into notepad and "be notepad". Do you want to block notepad to communicate by your firewall? Where does it stop?
Protection should be used on certain level. You need for example a good endpoint protection to stop the injection in the first place.
there is a slight problem with using DPI only, it does not detect UDP and not all sites are happy with the DPI inspection that is why there is a very big list of specific SSL/TLS exceptions which is not required for HTTPS inspection. There is also a bug in the current DPI ask Prism for the details.
The bug will be fixed in v18.0.3 MR-3.
Hi LuCar Toni, Thanks for giving your insight.
I understand your point of view, Nowadays there's even malware using DNS over HTTPS to communicate with C&C over Port 443, making it looks exactly as HTTPS Traffic for the firewall; At the same time making protocol enforcement useless, but in this case most discussions in the community about this is not entirely about security, but management.
LuCar Toni said:You can build many real L7 scenarios with XG, as the firewall backend allows such processes. But there are certain limitation like groups etc.
Let's talk about L7 Policies;
The problem here is not being able to create rules directly based on the application, It makes management a hell, you will always ended up with dozens or hundreds of "Application Filters", and every time you need to make a simple change, such as deny Google Drive, you will always see yourself editing a bunch of those filters because there's multiple of those different filters being applied on different users and groups - that needs to be blocked.
In the scenario above, if you could create a L7 aware Rule, all you would have to do is create a new rule on top that block this application, and select the users/groups.
And, well... Protocol Enforcement doesn't work that well anymore since pretty much >80% of the traffic is TLS encrypted; Also, since on v18 the new DPI Engine is capable to identify the known apps on any port, then I don't see It as a issue anymore.
It highly depends on the size of your setup / network and your goal. If you start to create multiple filters for multiple reasons, you will end up by editing through all of those rules (which you could shortcut by using API or XML). But i understand the issue at hand. I am simply here to tell you, what is possible "as of today". I know, there are other vendors, using different approaches.
There are certain few point of this story. You can split up this topic into multiple domain, like Security, management, control and enforcement. Also scaling is a huge point of it. With simple setups, it is quite easy to build up a secure application filter. If you go into the more complex scenarios, as you want to deny multiple apps because of different reasons, it can get more complicated.
There will come up other issue in the future. Lets call them "in-Apps". Something like Outlook in Chrome, Teams in Chrome etc. As such applications use the browser, you will see on application control products only "Chrome" as a user agent or application filter. There is more stuff on the to do list, to interact with the future.
XG does enforce protocol validation and I did the similar test as you mentioned above.
I am not sure exact configuration of your setup but I have done following and seeing protocol enforcement getting imposed. a. Created App filter policy with only "HTTP allow" followed by "Deny All".
b. Attached to Firewall rule : [ Have tried both as service "any" and "HTTP" only, there is no difference in result. Rule No #16
c. Initiate SSH traffic over Port 80, Application classified as SSH like yours on port 80 and Denied by App filter.
Thanks a lot for your answer, but there's two problems on this.
1) You will have to create hundreds of "Application Filter" to then apply over all firewall policies, this is not intuitive.
2) If the traffic isn't known by the IPS Engine It will bypass the "Action" of the "App Filter", here's an example:
Here's the App Filter Policy I've used.
Here's It showing It can block SSH running on TCP/80.
And here's Iperf3 traffic running on TCP/80 being allowed. Any application that isn't identifiable by the IPS Engine can bypass this.
The same applies for a Firewall Rule that only allows TCP/53 and UDP/53 for DNS, even if you create a Application Filter that only allows DNS traffic, you can still run a WireGuard VPN over UDP/53 and It will be allowed since It's not known by the IPS Engine.
There's also another issue. If the traffic have a known application classification on Sophos XG, even If it is HTTP traffic, the IPS Engine will not identify It as HTTP traffic - but as It's own application.
Here's the Application Filter I've used, which allows only HTTP traffic.
And here's the Rule being applied only over TCP/80.
Now here's what happens when I try to access an HTTP application over TCP/80, which should be also identified as HTTP, but as you can see It get's blocked because It didn't got identified as HTTP, but as "Baidu Website" and "Shopify". (Those are examples I used.)
EDIT: I didn't knew this worked on XG. Cool.
Its very well expected that after protocol analysis in this case HTTP, if further traffic gets classified as specific application in this case"Baidu Website" and "Shopify".
It should get allow/deny based upon final application classified and policy been configured.
Well, then protocol enforcement doesn't work at all on Sophos XG. The same applies if I allow only SSL/TLS (Application) Traffic only on TCP/443, If the SSL/TLS traffic gets matched to a know application, It won't work.
Good to know, Thanks.