Endpoint Protection

 View Only
  • 1.  Best Practices for Web Traffic

    Posted Apr 17, 2018 03:48 PM

    I was just curious what the best way to setup rules would be in regards to website browsing.
    We recently deployed SEP 14 to our environment, and are seeing a number of legitimate web traffic being blocked. Mostly SSL providers like globalsign.net and comodoca.com, as well as some website's itself like Equifax. 

    For now, we have been adding them to whitelist rules within Symantec's firewall, but we are a large company so this isn't a realistic solution when web traffic is unpredictable. 
    What would the risks be for creating a rule to allow all port 80 and 443 traffic through chrome.exe and iexplore.exe? I feel as though that's not likely the most secure solution.

    I would appreciate any input!



  • 2.  RE: Best Practices for Web Traffic

    Posted Apr 17, 2018 03:53 PM

    SEP really isn't the best solution for web filtering to be honest. Even allowing access to 80/443 won't stop much in terms of web categories that should be allowed/blocked or identifying malicious traffic. Locking it down to web browsers is ok but do you have other apps that communicate/need to communicate out?

    You could allow based on domains, ex. *.symantec.com but again you'd need to know your web traffic.

    Ideally, you want something that can block based on category and filters accordingly based on your corporate policy. SEP doesn't do that.



  • 3.  RE: Best Practices for Web Traffic

    Posted Apr 17, 2018 04:08 PM

    The problem is that currently we're not actually trying to block websites or apply a filter. We're just trying to stop our pretty much default symantec setup from blocking these websites and SSL providers by itself. It's really taking a liking to denying SSL providers and causing that website to not load or load slowly. Shall we just make a rule allowing port 80 and 443 for chrome.exe company-wide? That seems like the only solution I can think of. 



  • 4.  RE: Best Practices for Web Traffic
    Best Answer

    Posted Apr 17, 2018 04:12 PM

    I don't get why the default setup is even blocking these as there is already a rule in the default policy to allow this traffic, I believe it's called 'Allow all applications'. So unless a new block rule was created and moved above it then it really doesn't make sense to me. But since your aim isn't to do URL filtering than you can give your solution a shot.



  • 5.  RE: Best Practices for Web Traffic

    Posted Apr 17, 2018 04:23 PM

    Ah see that might be why then. We have no such rule, however I don't recall making any major changes to the default rule setup so I believe this just wasn't created by default? Regardless it's good to know the default setup of "Allow all applications" is much more broad then allowing the two ports for Chrome.exe. I thought my solution was too large of a blanket, but it seems better this way now.



  • 6.  RE: Best Practices for Web Traffic

    Posted Apr 17, 2018 04:26 PM

    It's always been in the default ruleset since I can remember but I suppose it could've been deleted at some point by an admin in your environment but I'm only speculating. It does allow all application traffic, which is IMO, too broad and dangerous. But it doesn't 'break' apps and SEPM admins should harden the policy based on their environment.



  • 7.  RE: Best Practices for Web Traffic

    Posted Apr 19, 2018 06:01 AM

    Hello,

    Can you provide a screenshot for bloking page and URL? By default, SEP would allow this kind of traffic and it is possible that something else is blocking what you have described.

    Regards,



  • 8.  RE: Best Practices for Web Traffic

    Posted Apr 19, 2018 02:31 PM

    Are you sure it's not Chrome itself doing the blocking?

    https://www.thesslstore.com/blog/chrome-66-launched-millions-of-websites-deemed-unsafe/



  • 9.  RE: Best Practices for Web Traffic

    Posted Apr 20, 2018 11:19 AM

    This is very useful information, and actually seems to be the answer to a few unrelated issues in our environment, so thank you! However I can confirm this is not the cause of the particular issue in the post since I can see Sym logs blocking Certificate Authority domains like Comodo SSL, etc. and Whitelisting them resolves the issue. 

    Seems adding a rule to "Allow All Chrome Traffic" for 443 and 80 resolved the issue, since our "Allow All Application Traffic" rule was deleted somehow. 

    Thanks everyone for the help!