wiki:WikiStart

Virtual Secure Network

A Virtual Secure Network (VSN) is a novel network service, providing remote users the security benefit of being behind a managed secure (corporate/cloud) network, while providing Internet performance more typical of an (insecure) direct connection. A VSN is analogous to a Virtual Private Network (VPN), in that it offers security protections like firewalls, multiple Antivirus scanners, IDSs and IPSs to the remote users, however VSN guarantees additional benefits of low cost for the management and better performance for the end users. Employing VSN architecture in the cloud to offer security protections as a subscription service can guarantee lower cloud costs and better user experience.

Why VSN?

A corporate network typically has IDSes, firewalls, and malware scanners to protect the machines on the network from attack. However, employees may use devices with sensitive data in remote locations. This leaves the company with a choice: either have the remote users VPN their traffic back to the corporate network for protection; or let its employees connect directly to the (insecure) Internet. The former choice can be very slow for users as well as costly for the organization, while the latter increases the security risk. Many companies though aware of the security risks, allow company devices to directly connect to the internet when outside the company network to reduce costs. Highly protective companies (like the government offices) force users to use all-time-VPN without providing any enhancements to improve the user experience. We address this problem by proposing a novel network service called Virtual Secure Network (VSN), which tries to reduce the enterprise costs and improve the user experience simultaneously.

Briefly, how does VSN work?

A VPN of an enterprise generally has two use cases.

  1. Extend already deployed company network and host protections to remote users.
  2. Allow remote users to access internal network resources or services.

Our VSN service focuses only on the initial use case of VPN, and does not alter the second use case in anyway. A VSN tries to guarantee better user experience and reduced costs as compared to the case when all-time-VPN is enforced.

a. Core Idea

Our approach is based on the fact that there is considerable overlap in the content that different users are interested in. If an object (such as a web page) passes all the security screenings deployed, without triggering any alarms, we can consider the object to be safe as per the current security configuration (i.e., with respect to the deployed IPS/antivirus signature databases and detection engines). If another user requests the same object and the object's content has not changed since the last screening, then the object can safely be retrieved directly from the Internet. But in order to deploy such an approach, the user needs a mechanism to determine whether the to-be-requested object has passed the security screenings previously. To allow the user to make a local determination, we propose a novel scheme based on distributing hashes of previously tested content to the users. Clients that want to obtain content on the hashlist do so directly over the Internet but have the same security assurances as though they were in the corporate network. Any new content (not in the hashlist) would be requested through the VSN server.

VSNarchitecture.jpg


How to obtain current VSN implementations?

The SVN repository can be accessed here:

SvnUrl?

All the libraries needed to run VSN are included in the repository, and should be downloaded when you perform SVN update.

Instructions to run the code

You need to have JAVA JDK pre-installed as you need to compile and run the java code. In future, we plan to release an executable version of the VSN client and server codes.

There are two main components of VSN project code- VSN server and VSN client. A VSN server can handle multiple clients, but currently a client can only interact with one server. Both the client and server can run on different/same machine.

For compiling the server/client code on WINDOWS, use the following command with appropriate path substitutions:

javac -classpath "pathto\lib\derby.jar" program.java

For executing the server/client code, use the following command with appropriate path substitutions:

java -classpath .;"pathto\lib\derby.jar" program [arguments]

If compiling and running the code on a *NIX machine, you need to replace ";" (semicolon) with ":" (colon) in the above commands.

Both the client and the server code take in some command line arguments to learn which ports to use and how to communicate with the server. For the VSNClient, the command line arguments needed to be provided are:

java -classpath .;"pathto\lib\derby.jar" ClientProxy listen_port ServerIP/hostname Server_port listen_udp_port server_udp_port

Similarly, for the VSNServer:

java -classpath .;"pathto\lib\derby.jar" ServerProxy listen_port listen_udp_port alpha max_users

With no arguments, the client code assumes the server runs on the same machine. The client listens for connections of port 5555 and listens for UDP connections on port 5600. The server listens for HTTP connections on port 5556 and UDP requests on port 5601.

You need to configure your browser to use the local VSN client proxy server, by setting the proxy IP to be "localhost" and the port to "5555" (or the new port number, if you changed it). For instructions to set proxy details in the browser, check your browser help instructions.

People

Last modified 4 years ago Last modified on Aug 31, 2012 12:42:11 PM