Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Subscribers 8 subscribers
  • Views 2225 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

Do you have a defence against VPN applications with Sophos UTM?

icbbne

Since Sophos support couldn't help me with this case I decided to ask the community what is their solution. If I am missing something please let me know so I can correct my UTM accordingly.

 

Here are the details of the test, please compare with your own system and check if you are able to prevent a user/s who using a VPN application going restricted websites and other stuff.

  1. SSL Inspection operational on UTM- You have installed the certificate on the client machine (actually doesn't matter at all)
  2. Client installs a VPN app such as XVPN (do not turn on XVPN yet!) https://xvpn.io/
  3. Try to access a restricted website and ensure you are blocked!
  4. Turn on XVPN and try to access the restricted website again to see the result

 

Our findings are;

  • We absolutely have no control on a traffic if VPN applications in use by any client (with SSL certificate or without)
  • Clients even able to bypass the UTM with Chrome extensions (we removed extensions via GPO on domain joined workstations eventually as a workaround)


This thread was automatically locked due to age.

Top Replies

  • in reply to emmosophos +2

    I have a little addition to it. On my side I could reproduce it too, but the application went thru. So I went into the firewall and concluded that the application uses a few ports to try to connect. 

    Blocking all but required ports will be effective (as stated before)

    To narrow down I will put the used ports below. If you require an any:any rule (not recommended) please place a blockrule with the following ports above your any:any (or on position "top")

    destination ports:

    14393

    19535

    20028

    2463

    7594

    7805

    8366

    By the way, the Sophos XG does do a better job in this and blocks the application properly, without extra firewall rules.

     I think the definitions for xvpn needs some adjustments.

    Regards,

    Arno

    Jump to answer
Parents
  • +1

    In addidition to what others already wrote, this may be helpfull to you.

    Most vpn clients which makes connection over 443 (https) do not like ssl interception. So using webproxy in transparant mode with ssl interception should block most of it.

    For those using openvpn you can kill outbound udp/tcp 1194

    Secondly, block webtraffic by creating firewall rules towards any:80 and any:443. In other words: do not permit any webtraffic besides what is done over the proxy. When you create your outbound blockrules, block also all other, not needed ports. (to prevent massive interuption in production networks I use allow and blockrules above the (often) existing any:any rule (so bad, but I see it often existing!) and switch on logging on all the created rules, as well to the any:any rule.

    With following the firewall log (or syslog receiver) you can tweak the restrictions nicely.

    After tweaking, I switch often most logging of, unless there is a syslog receiver available and extensive logging is required for compliancy.

     

    Regards,

     

    Arno

Reply
  • +1

    In addidition to what others already wrote, this may be helpfull to you.

    Most vpn clients which makes connection over 443 (https) do not like ssl interception. So using webproxy in transparant mode with ssl interception should block most of it.

    For those using openvpn you can kill outbound udp/tcp 1194

    Secondly, block webtraffic by creating firewall rules towards any:80 and any:443. In other words: do not permit any webtraffic besides what is done over the proxy. When you create your outbound blockrules, block also all other, not needed ports. (to prevent massive interuption in production networks I use allow and blockrules above the (often) existing any:any rule (so bad, but I see it often existing!) and switch on logging on all the created rules, as well to the any:any rule.

    With following the firewall log (or syslog receiver) you can tweak the restrictions nicely.

    After tweaking, I switch often most logging of, unless there is a syslog receiver available and extensive logging is required for compliancy.

     

    Regards,

     

    Arno

Children
No Data