Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 26739 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

Application Filter Whitelist

JulianTekook

Hello,

 

I think that I might just not doing it right, but I cannot for the love of god, create an application filter which has it's default action set to "Deny".

If I go to Applications -> Application Filters -> Add I can enter the following:

Name, Description and Template.

And I can only choose the predefined templates which all are default to allow.

Since there is no option to change the default action after creating the application filter, there is no way to create an application filter which works as a whitelist.

All I can do is a blacklist.


Is this a bug, or just not possible at the moment?

Kind Regards,

Julian



This thread was automatically locked due to age.
  • 0 in reply to PhilippeGressier

    PhilippeGressier said:

    In my case, I have a default rule which allow my children to update app on play store without authentification : I use a web filter to allow only a limited website list (google stuff .. and cdn) and I use the application to avoid google streaming for example.

     
    So you have a firewall rule applying only to HTTP/HTTPS.  You have a Web Policy that has a default Block, with rules above that allow certain domains using either a custom category or URL filter?
    In your case I would continue to refine your web policy to block the things you don't want - so that everything is in one place.  You also get clear block pages when something is blocked.
    If you want to you can use an Application Filter to Deny Google Streaming instead of Web Policy.  You don't care if the Application Filter denies Skype because you don't have those ports open in the first place.  You don't care if the Application Filter denies Bing because the Web Proxy already denies it first and better.
     
    The Web Proxy is much better at filtering port 80/443 traffic than the Application Control.  The only thing App Control gives you if a few sophos-managed signatures that are updated automatically and you cannot really see the details of.  But if you are already creating hostname/path specific filtering with the Web Proxy, its better to continue to refine that.  If google changes how they structure things the application control rules will get updated automatically - however if you are also doing your own path based allows/blocks you'd have to update them yourself.  If on the other hand Sophos decides to start managing another part of google as an "application" and you are using App Control, then it will be allowed or denied as per how you've set up your app control policy
     
    I see no need for a Deny All rule.
  • 0 in reply to JulianTekook
    JulianTekook said:

    I wanted to do both.
    Allow only the ports neccassary but still check for invalid applications.
    Take HTTPS and OpenVPN vor Example. Could be using the same port, but are completly different ports.
    Also my sophos salesman told me, the XG is blocking/allowin Applications not ports. Or is this only for WAN Traffic?
     
    You can use Application Control to do just that.  You don't need a default Deny All to do it.

    The XG is blocking/allowing ports first (as part of firewall) and then on anything that is allowed through the firewall is blocking applications using deep packet inspection.  An application rule cannot override a firewall rule.  An application rule cannot block traffic on a port that it does not have an application for.
     
    Let me give an example:
    You have a firewall rule that allows "service" "DNS" - which means it allows traffic on port 53.  So all packets of all types are allow to travel over port 53.
    You then have on the same firewall rule an application policy that says Deny the application "DNS".  So all packets that match the DNS signature are blocked.
     
    The way it works is that any traffic that goes over port 53 that is not DNS would be allowed.  So if you had say a custom web server that listened on port 53 instead of port 80, then it would still serve pages.  Because the firewall/application rule says "Open port 53 to everything but drop DNS packets".  If you turned it into an application policy that said "default Deny All" the exact same thing would occur.  The HTTP traffic over port 53 would still be allowed because there is no "application" defined as HTTP traffic on that port.
    Therefore if you really want to close up the system you really should not be creating a firewall rule that opens port 53 in the first place, expecting that Application Control will then close it.
     
    Julian, lets say that you want port 443 to allow HTTPS traffic and deny OpenVPN.  Have your firewall rule apply to "Service HTTPS" (port 443) and have an application control policy that is Deny OpenVPN, default Allow.  No need for a Deny All policy.
Unfiltered HTML