Thread Info
  • Locked Locked
  • Replies 2 replies
  • Subscribers 4 subscribers
  • Views 5158 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

Protecting internal network from mobile devices.

DouglasFoster

Any time a mobile device crosses from the Intranet to the to the Internet, it loses the protection of perimeter devices like UTM.  Then when it comes back in, it might bring malware acroos the boundary, particularly ransomware.   I am curious what others are doing to hedge this risk?

I think Sophos Endpoint and/or Sophos Mobile Control are supposed to solve this by replicating UTM webfiltering rules to the device, and

I don't have eother product yet.   If you have them, have you found that it is a sufficient defense?   Have you integrated with a Network Access Control solution as well?   If so, what does the NAC check before allowing the device onto the internal network?  Any other strategies?



This thread was automatically locked due to age.
Parents

  • VPN client connections are a variant of this problem, because VPN permits the remote PC to act as if it is behind the perimeter, and by default a VPN connection allows traffic to all ports.  

    For home computers, we know that the quality of web and email defenses are likely to be weak, so it is safest to assume that a VPN client device is infected, and that the VPN policy needs to ensure that the infected client cannot damage the internal network.  So it seems that the most important defense is to prevent file transfer technologies, by blocking at least these ports:

    • NetBIOS over TCP port 139
    • SMB over TCP port 445
    • NFS ports 111 and 2049
    • FTP port 21
    • SFTP/SCP/SSH port 22

    File transfer blocks will also hinder unauthorized data exfiltration.

    Keystroke grabbers cannot be ruled out, but hopefully they are made less useful because 2-factor authentication prevents externally-visible logons from being replayed, and internally-visible logins are not usable if the externally-visible login fails.

    The superior approach is to block all ports by default, then enable only specific ports to specific destinations for the specific tasks needed by specific users.

    • Terminal emulation to specific desktops (RDP, VNC, SSH, Telnet) gives the user a high level of functionality but a fairly strong boundary between the client and the internal network.   For RDP, you need to block USB port and local drive redirection or RDP becomes a possible file transfer method.
    • Allowing web connections on known ports to known servers should be fairly resistant to malware attacks.  Consider, however, that some risk is added if the VPN client is bypassing your WAF site and connecting directly to the real webserver. 

    Everything gets more risky if you are trying to provide a wide-range of office-like capabilities to a remote user, rather than a short list.    Perhaps other infrastructure, like the Microsoft Direct Access technology mentioned in another recent post, can make this risk tolerable.

    How are you keeping safe from VPN-client attacks?

     

Reply

  • VPN client connections are a variant of this problem, because VPN permits the remote PC to act as if it is behind the perimeter, and by default a VPN connection allows traffic to all ports.  

    For home computers, we know that the quality of web and email defenses are likely to be weak, so it is safest to assume that a VPN client device is infected, and that the VPN policy needs to ensure that the infected client cannot damage the internal network.  So it seems that the most important defense is to prevent file transfer technologies, by blocking at least these ports:

    • NetBIOS over TCP port 139
    • SMB over TCP port 445
    • NFS ports 111 and 2049
    • FTP port 21
    • SFTP/SCP/SSH port 22

    File transfer blocks will also hinder unauthorized data exfiltration.

    Keystroke grabbers cannot be ruled out, but hopefully they are made less useful because 2-factor authentication prevents externally-visible logons from being replayed, and internally-visible logins are not usable if the externally-visible login fails.

    The superior approach is to block all ports by default, then enable only specific ports to specific destinations for the specific tasks needed by specific users.

    • Terminal emulation to specific desktops (RDP, VNC, SSH, Telnet) gives the user a high level of functionality but a fairly strong boundary between the client and the internal network.   For RDP, you need to block USB port and local drive redirection or RDP becomes a possible file transfer method.
    • Allowing web connections on known ports to known servers should be fairly resistant to malware attacks.  Consider, however, that some risk is added if the VPN client is bypassing your WAF site and connecting directly to the real webserver. 

    Everything gets more risky if you are trying to provide a wide-range of office-like capabilities to a remote user, rather than a short list.    Perhaps other infrastructure, like the Microsoft Direct Access technology mentioned in another recent post, can make this risk tolerable.

    How are you keeping safe from VPN-client attacks?

     

Children
No Data
Unfiltered HTML