We'd love to hear about it! Click here to go to the product suggestion community
I have various rules for users with different time restrictions, and then a final rule to always allow various sites and services.
I have added an application policy called "Always Allowed" which includes the application "NTP". It isn't working though.
The application log shows the destination port of 123, but no Application Category or Application, and an Action of Denied. The Policy ID is my catchall rule, and the Message ID is 17051. I'm guessing that port 123 isn't getting correctly detected as NTP and so is being blocked.
The particulars of my rule are:
Source Zone / Network / Time: LAN / Any / All the time
Dest Zone / Network / Services: WAN / Any / Any
Match known users: unticked
Malware scanning: Only HTTP ticked
Intrusion Policy: None
Traffic Shaping Policy: None
Web Policy: None (I have tried Allow All too)
Application Policy: Always Allowed (my rule that includes NTP)
Any idea why this isn't working?
what have you setup as your NTP sites, test you can access them using the XG tools?
In reply to rfcat_vk:
NTP works if my device is covered by the for the default Allow All applications rule, just not with my application rule that only allows NTP. And the Application Log shows that port UDP/123 isn't even being detected as NTP.
In reply to jamesharper:
Web and Applications filter should be used only on http/https traffic because XG manages this traffic by inspecting the encapsulated traffic inside the HTTP/HTTPS. For controlling other not-http/s traffic, separate firewall rule must be used.
In reply to lferrara:
That makes no sense. Why can I create an application rule for NTP if I can't actually use it? There are application definitions for all sorts of non-HTTP(S) traffic.
Applications and Web Filters are used to manage only http/s traffic or traffic that is encapsulated inside http/s traffic. Allowing NTP service (udp 123) is done via a network firewall rule without App or Web filters applied. NTP should not be even inside the list of Applications (Maybe a Sophos Mistake).
I'm with you on this one James.
It seems the Application rules on XG are both misunderstood and bug-laden. I've noticed some application rules that seem to have ZERO effect (IRC for one) and others (SSH) that work fine. Unfortunately, the only way to identify which application definitions actually work is to test each one. Fun.
Anyway, a work-around would be to create a single firewall rule at the top of your chain that allows any traffic from LAN to WAN where the destination protocol is NTP. Granted, this is just using TCP/port combinations rather than protocol/packet inspection, but should be a viable option.
In reply to Gary Parr:
Hi James and Gary,
I still do not understand few things:
As I wrote many times in this thread, Application filters is able to block/filter http/s traffic because many Products are encapsulating their SW inside Http/s tunnel and so if an application firewall is not used, encapsulated traffic is not filtered.
NTP, IRC and other not-http/s applications should not be into Application filters. It is like you try to block not-http/s traffic using Web Filters.
Aditya Patel, sachingurung can you investigate why inside the Application filters there are not-http/s applications?
Here Users are use it in the wrong way.
Looking at your FW-rule description, I can see all the Services are Allowed. I don't see a reason why the NTP is blocked when the services are open and Application Filter tells XG to Allow All. If you suspect that Application Filter is blocking NTP services then check, Log Viewer > Application Filter; it will only log Denied Traffic. This will give you a general idea if the Application Filter is doing a false positive and we could raise a request to fix that.
In reply to sachingurung:
can you explain in few lines how to properly use the Application filter?
I guess that in the Application lists there are some Apps that should not be there. Can you check internally and reply here back.
I did some testing and found the following:
I do see Application Filter blocking some non-HTTP(S) traffic, in particular port 5223 and 5228, but as a general rule, as has been repeated stated here by others, Application filtering does not do anything for non-HTTP(S) traffic.
I'm a little disappointed, but at least now I know.
The evidence suggests that the application filter has little to do with HTTP(S) traffic. For instance, given the following application filter...
... one would expect none of the designated protocols to get blocked. Well, except Jabber perhaps if you were using a Cisco client on port 80. I'm not, my Jabber traffic is XMPP on port 5222 and was blocked just fine, along with LDAP and SSH which, again, are pretty unrelated to HTTP(S). The only ones not caught by this example app filter are IRC and NTP.
there is some confusion here on this thread. You should implict deny principle and allow only what is needed. Application and web filtering came out after the first SW houses used "encapsulation" on TCP/IP. They re-encapsulate packets inside the big tunnel 80/443 ports. Because the first version of Firewall were not able to scan inside the 80/443 ports, those application were allowed. Even now, if the signature on the Firewall does not exist, you will see a lot of HTTP/S traffic or undefined 80/443. So, I repeat what I already wrote, Application filters are only used to scan the "big" tunnels (80 and 443) in order to catch and block/allow packets that are encapsulated and travel within the http/s tunnel.
It is strange that inside the Application filters there are not-http/s applications, like NTP.
Michael Dunn can you add some more technical aspects/information here?
I completely agree that a "proper" implementation should be Deny All and then poke holes as needed. That being said, there is no logical reason the firewall rules would not work in the other direction as well... allow all and block as needed. Not a good model for corporate use, but perhaps a more common practice for the home user? Regardless, I can flip the rule around to block all and allow only the identified protocols and it still has the same issue where some are identified, others are not.
As for the question of application filtering only working on HTTP(S) traffic... I agree we need an answer from Sophos. Your explanation makes sense, but just looking at the current XG model seems to indicate a different direction. Perhaps things have changed a bit since they were first implemented? If you look at Web -> Categories you will see Content Delivery, Applets, ActiveX, P2P torrents, etc. Unless Sophos is trying to maintain a URL list of every single domain that has applets and activeX content, it would seem that lots of the encapsulation inspection has moved into the Web > Categories section. Then, take a look at what is currently in the Applications > Application List and filter on Infrastructure or Network Services categories. There are clearly lots (and lots and lots) of items in those categories which are not expected to be HTTP(S) encapsulated traffic. Additionally, look at all of the applications defined as type Client/Server. Again, not expected to be HTTP(S) encapsulated.
I'm not saying you are wrong about what the Application Filter is supposed to be used for, but XG currently looks a whole lot like it should work the way I was expecting.
Ok, first off all, this is not my area of expertise. So take everything that I'm about to say as just my understanding and I could be wrong.First of all, Applications are used for non-HTTP/HTTPS all the time. This is implemented by the IPS engine doing generic packet inspection on any incoming packet on any port. In the case of HTTPS, the detection is done by the httpproxy (since it can read inside the encrypted packets) for everything else the detection is done by IPS. Enforcement (dropping packets) is done by IPS. At a pure guess, non-HTTP/HTTPS is somewhere between 5-25% of the definitions (behind the scene). Sorry, Iferrara, though you are correct in what the majority of the Applications are for, there are many that don't fall in your definition.Secondly, you must understand what "Allow" and "Block" really mean. "Allow" does not mean the traffic is allowed. It means that traffic will not be blocked at this stage.For example, think of the HTTP Proxy. Lets say you get set Search Engine to Allow. Now you go to your browser and try to access Google and you can't. Why? Because in the firewall, HTTP and HTTPS are not allowed services. Ok, so you allow them. You can access Google. And suddenly you get a block page. Why? You were blocked on virus. Even though your policy says "Allow Search Engines", it actually means "Don't block due to the fact it is Search Engines". Your traffic can still be blocked for many reasons, even though it says Allow.So lets take that to NTP and applications. Setting an Application of NTP to Allow doesn't mean NTP is allowed by everything in the XG system. It means NTP is not blocked by the IPS / Application Filter. It may still be blocked by the firewall ports not being open.So... If NTP requires you to have the firewall port / service for NTP open - why bother having an application definition for it? Well, what if you want to put time restrictions on when it is allowed. Or you want to block some things with the Application Filter but still allow NTP. I'm not sure all the use cases. But they decided to include NTP as a detectable app.What does this mean - if you want to globally allow NTP, do it through a firewall rule that allows the NTP port/service. If you want more granular control, have the firewall rule allow it and then restrict it with the Application Filter.Finally, now that you understand that "Allow" does not actually mean Allow, you should understand that a Application Filter with a default of Allow All and certain applications set to block does not open you up for any additional access or attacks. I think the only time you want to use a Block All is if you were trying to do something like a server or IoT device lockdown.In the same vein, 95% of the time your application filter rule will say Action Block. The main reason for having Action Allow is to override a lower priority Block. For example an application filter may be: Allow GMail WebChat, Block Instant Messengers, default Allow.So that all being said - I have no idea if the NTP application definition is correct or not, works or not. But if someone wants to test it, they should have a good understanding of how it should work (AFAIK):1) With no application filter at all, and a matching high level firewall rule with a Service of "NTP" the NTP traffic should be allowed. (If not, check firewall logs)2) When (1) is satisfied, an Application Filter of Block NTP, default Allow should block the NTP traffic.3) When (1) is satisfied, an Application Filter of Allow NTP, Block (select All), default Allow should allow the NTP traffic.4) When (1) is satisfied, an Application Filter of Allow NTP, default Block should allow the NTP traffic.5) With no firewall that has a service of NTP, the NTP traffic should be blocked.6) With no firewall that has a service of NTP, and a Application Filter of Allow NTP, the NTP traffic should be blocked.
In reply to Michael Dunn:
Thanks Michael for your partecipation here.
It is strange that Sophos XG is controlling some non-http/s traffic via IPS. This is make no sense and also troubleshooting scenario can be quite complicated. UTM9 did not use IPS and Application filter for blocking non-http/s traffic. I know even other Vendors do the same think like UTM9.
Sorry, but I do not understand scenario 6. If the App Filter allows NTP, latter should be allowed and not blocked. Maybe I missed something.