IPSec with VNS3: Part I

IPSec with VNS3: Part I

Internet Protocol Security (IPSec) is used to encrypt communications between two computers over the internet. Usually it is done between between security gateways to allow two networks to communicate securely. On the data center side this will be done for the most part on physical boxes manufactured by the likes of Cisco, Juniper, Fortinet and others. In the public cloud it is virtualized. Cohesive Networks VNS3 is one such device that allows you to easily configure these secure connections into your cloud private network. Whether you are running a hybrid cloud, are an ISV that needs to connect to customer sites or are implementing a multi cloud strategy VNS3 can provide a stable, secure and simple solution.

VNS3 can manage as many IPSec connections as you need, the only limit is the underlying instance resources. You can scale your VNS3 instance with the number of connections. It supports both policy and route based connections and supports a wide range of algorithms, hashes and Diffie-Hellman groups. In short, VNS3 can connect to just about anything out there. It’s highly configurable design lets you match exactly what it is communicating with. This all makes VNS3 a very stable solution.

Setting up VNS3 is a breeze. You can launch it out of your cloud vendor’s marketplace and pay by the hour, or contact Cohesive Networks for longer term billing. VNS3 should be placed into a public subnet. Once launched you will need to either in AWS, turn off source destination checking, or in Azure, enable IP Forwarding on its network interface. In AWS you should attach an Elastic IP (EIP) to it or in Azure a Public IP Address. Once it is up you can manage it via its web interface. You will need to open up TCP port 8000 in your security group. Then open a browser and go to:

      https://:8000
      The default admin username is: vnscubed

In AWS the default password is the instance id, in Azure the default password will be the virtual machine name followed by a hyphen then the private ip (ex. MyVNS3-10.0.0.1)

Once you have logged in you should change the admin and api passwords.

The IPSec configuration page can be found under the Connections section on the left hand side contextual menu. From there you will want to click on the “New Endpoint” button and will see the IPSec configuration form.

Now it is just a matter of filling in the parameters for the endpoint you will communicate with. Typically you and the other party will agree upon a set of algorithms, hashes and dh groups as well as NAT-T or native IPSec and IKEv1 or IKEV2. While VNS3 does a good job of auto discovery it is best to make sure that both sides are explicitly the same. We provide a simple syntax for VNS3. An example might look like:

phase1=aes256-sha2_256-dh14
phase2=aes256-sha2_256
pfsgroup=dh14
phase1-lifetime=3600s
phase2-lifetime=28800s
dpdaction=restart
dpddelay=30s
dpdtimeout=90s

VNS3 simplifies this process by putting all of your configuration on a single page.

If you are creating a policy based IPSec connection you will next need to create individual tunnels for your connection. This is done after the creation of the initial endpoint. After the endpoint is created you can create a “New tunnel” from the action drop down to the right of your endpoint. This will be your local subnet and then the subnet on the other side of the connection that you will be communicating with.

With route based IPSec we support both Virtual Tunnel Interface (VTI) and over GRE, useful for sending multicast packets. If you are utilizing a VTI route based IPSec VPN you next want to set up a “New eBGP Peer” from the action drop down.

Your IPSec configuration should now show as connected.

In the next parts in this blog series we will dive into the tools we provide to troubleshoot a faulty connection, interesting things you can do with our firewall to transform the tunnel traffic, and some plugins we use to solve common problems.

Zero Trust External Privileged Access Management and VNS3

According to a survey conducted last year by Centrify, a leader in the privileged access management space, 65% of companies are sharing root level access credentials in at least some instances. This backs up Forrester Research’s long held claim that privileged credential abuse is the leading attack vector. For network devices this figure rises somewhat as the survey showed that 68% of companies are not securing their network devices with privileged access control. This is not surprising as historically network devices have had single or few local users. Perhaps it is because smaller more trusted teams managed the network infrastructure. Or that when bootstrapping or troubleshooting network devices , relying on network connections to user directory servers could become problematic.

Cohesive Networks has been guilty of this in the past. The challenge of implementing the principle of least privilege has always been complexity. The more complex a system or control is to manage the less secure it becomes. We have been putting a lot of focus on various methods of access management for our VNS3 cloud security edge controller that are simple to manage and operate.

In a previous blog post we discussed how we have adopted Access URLs and API Tokens. Both of which allow for time-based access to VNS3. Where API tokens are useful for systematic access between the control and data planes and Access URLs are incredibly useful for one off access, we still needed to address long living user accounts and have done so by implementing LDAP authentication for VNS3. We have had this capability for our management server for a while and the time has come to extend that to our individual VNS3 network controllers.

In the world of Zero Trust every user needs to have an identity. Ideally your identity system will enforce principles like password rotation and complexity standards. Things like managing on-boarding and off-boarding of authorized users, wether into or out of the system or groups, is what these systems are designed for. By shifting this function away from the VNS3 network device and its operators we allow you to not only to manage and enforce better security practices but address other corporate realities. Codifying some of the principles of Zero Trust are things like ISO 27001 and 27002, SOC and other compliance regimes which call for the segregation of duties. The people who maintain your privileged access management systems can’t be the same people who utilize them.

You can now manage your access to your VNS3 controller through integration with LDAP, along with its Active Directory variant, and the usage of groups. We support encryption to your LDAP server via Secure TLS (StartTLS) and LDAPs utilizing certificate authentication.

VNS3 LDAP integration page

This new capability provides some really good improvements for VNS3 access control. However for those who are looking for a method that goes beyond “something you know”, security architects can add on “something you have” by utilizing the VNS3 encrypted overlay network in tandem with LDAP identity management. The VNS3 encrypted overlay network makes use of unique X.509 certificates. These give you your network identity to participate in machine to machine communications. In order to access the VNS3 controllers management interface, which runs on TCP port 8000, you could restrict access to only break-glass endpoints while allowing a broader access to UDP port 1194 where the overlay network operates. In this way network operators would need to first establish a TLS connection to the VNS3 controller with their individually issued certificate and through the established tunnel they would then connect to the VNS3 controller via it’s own overlay address. A further way to implement Zero Trust policies.New Paragraph

Identity Access Management: Zero Trust Networks

As more and more traditional business infrastructure is being migrated to the cloud, traditional enterprise security and common corporate security practices are no longer enough to keep networks safe. Even as far back as the 2014 Sony Pictures Entertainment hack we’ve seen traditional, perimeter-focused security prove ineffective against attacks originating from within and beyond the network. During this attack, hackers were able to penetrate the perimeter firewall and access the entire flat network in a large-scale east-west exploit. In 2015, large enterprises like Google, Inc. began moving their corporate applications to the cloud with a heavy emphasis on a model where corporate data can be accessed from anywhere with the right device and user credentials. Facing the reality of a global network of networks, the traditional strategy of forming a security wall around an internal network is giving way to a many access point approach. This new Zero Trust strategy emphasizes protecting these access points from threats both within networks and without.

What is a Zero Trust Network?

Zero-Trust is a “never trust, always verify” strategy that relies on network segmentation and endpoint authorization rather than a single, unified, external firewall. This approach to network security assumes that no entity is trustworthy by default, leveraging application segmentation and “micro-perimeters” within a network to protect critical applications and data while preventing lateral movement.

A Zero Trust network strategy addresses many common security concerns, including access management, authentication & connectivity, and endpoint & data security. Any access to network resources must be authenticated, including network management activity and applications. Authentication involves supporting industry standard authentication protocols and user directories for any access point to the network, including applications, endpoints, and network connections. Once authenticated, no longer can a single verification into a network enjoy unlimited lateral access within the network. Zero Trust involves the constant verification of users, applications, and data flows within and between networks and data, assets, application, and services micro-perimeters.

Allowing access to network management applications is a key component in a Zero Trust strategy. Network administrators require the necessary access to manage the network, but supporting Zero Trust means providing access for only what is needed, possibly for a limited time, with the ability to shut down access if a threat is recognized. Different organizations have different processes, use cases, and critical elements when it comes to network management.

Traditionally, network devices have one set of administrative credentials used not only for logging into network management applications but also in application scripts. The concern and threat here is that the “keys to the kingdom” credentials are dispersed throughout potentially many network administrator users and possibly in scripts or in repositories. These concerns are even further complicated by a password change. Incorporating industry standard identity protocols such as LDAP authentication with official directories enables users to be managed centrally, decreasing the risks of duplicating another user management system.

How to Build a Zero-Trust Network with Cohesive VNS3

New approaches and innovations continue to push us towards a Zero Trust strategy that allows for the necessary access management for users and applications without creating security holes. Network managers have to first understand the use cases required for accessing network management applications and scripts to work with vendors to provide access management solutions. If a network administrator has a use case to provide temporary access to a key vendor to support their technology, a typical approach may be to provide a temporary user account. But this now involves provisioning a user account with appropriate password policies, supporting forgotten passwords, eventually removing the account and any other actions required for a secure identity management environment. Maybe another access mechanism could be provided, that was secure, provides the necessary access for a limited time and automatically expires, with the ability of an administrator to terminate access if any threat is recognized. The key point is to provide a toolbox of secure options and use what is best for the use case.

 

Cohesive Networks works with customers to build that toolbox of secure network access management options, supporting a Zero Trust policy for all access points in the infrastructure. VNS3’s API provides the ability to programmatically provision expiring access creds as well as build your network segments and perimeter policies, allowing you to build an encrypted network entirely declaratively in code. In the coming weeks we’ll be releasing more in-depth discussions of the approaches we take with VNS3 to enable you to create a secure Zero-Trust network, including how we approach access URLs, API tokens, and LDAP integration.

VNS3 Empowers 30-Minute HIPAA-Compliant IntelliGuard Deployment

VNS3 Empowers 30-Minute HIPAA-Compliant IntelliGuard Deployment

Intelliguard stock photo

IntelliGuard recently engaged with consulting group Six Nines to address the “scalability, flexibility, and cost optimization” of their Microsoft Azure deployment. “By moving to AWS, IntelliGuard sought to design its platform architecture for HIPAA-compliance and enable seamless scalability, rapid development capabilities, and provide more features—such as advanced tooling in machine learning (ML) and high availability and replication features—to its teams.” As a APN Advanced Technology Partner, Cohesive had the pleasure of joining the team in order to complete this project, leveraging VNS3 to create an encrypted, HIPAA-compliant overlay network and site-to-site VPN. The success of this project has enabled IntelliGuard to automate the HIPAA-compliant deployment of its entire RFID Inventory Management System down to an impressive 30 minute window, while allowing for shorter and less painful release cycles that “drive value to the business more quickly.”

Click here to read the full AWS success story.

Announcing AWS Quick Start Reference Deployment for VNS3

Announcing AWS Quick Start Reference Deployment for VNS3

Want a HIPAA/HITECH compliant application deployed to AWS in minutes? Read on!

We’re proud to announce the release of our first AWS Quick Start reference deployment for configuring and launching our VNS3 overlay network for your cloud application. Working closely with Amazon we’ve leveraged the proven power of AWS CloudFormation to take our secure and scalable solution and make it even more accessible. With our Quick Start deployment, VNS3 can easily secure your cloud application to HIPAA and HITECH standards in as few as fifteen minutes, supported by best practice tools and strategies for automating your infrastructure deployments.

Check out our Quick Start Guide here! Keep reading for more information about this release.

VNS3 AWS Quickstart Architecture

Save Time

Our Quick Start was built by AWS and Cohesive Networks solutions architects to help you automatically deploy a VNS3 topology quickly and easily. Don’t worry about high availability and security, we’ve included it for no extra charge! Build your production deployment fast and start using it now.

Reduce Complexity

Simple (not to be confused with simplistic) is secure. VNS3 provides a generalized approach to encryption across your cloud deployment. This enables you to field a clean VPC Route Table and Security Group configuration to reduce attack surface and minimize misconfigurations.

Control Encryption

AWS provided and controlled, symmetric encryption with common shared keys isn’t enough for regulated industries. Customer controlled encryption with VNS3 is essential to securing PII/PHI in order to pass HIPAA audits. VNS3 as demonstrated in this Quick Start Guide provides a simple and programmatic way for achieving HIPAA compliance.

Added Bonus

Do you use blocked protocols like UDP multicast? The VNS3 encrypted overlay network deployed by this guide allows you to redistribute UDP multicast within your AWS VPC deployment. Now you can apply the same design principles to your cloud applications, whether designing cloud native or lifting and shifting.

Moving Forward

Following the successful launch of our first AWS Quick Start Guide, we’re excited to move forward and create new reference deployments for all the various use cases VNS3 supports. We’re cooking up AWS Quick Start Guides that deal with more complex peered VNS3 topologies, demonstrating different High Availability and Network Federation capabilities. We are also working on an Azure QuickStart template for deploying the encrypted Overlay Network for Microsoft Windows VMs later this summer.

An intro to Internet Protocol Security

IPsec: Internet Protocol Security

Internet Protocol Security ( IPsec ) is a set of protocols defined by the IETF, to provide IP security at the network layer. IPsec uses cryptographic security services to protect communications over Internet Protocol (IP) networks. IPsec supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (encryption), and replay protection.

You can use IPsec to protect data between:

  • a pair of hosts (host-to-host),
  • a pair of security gateways (network-to-network),
  • a security gateway and a host (network-to-host).

IPsec is end-to-end, operating at Layer 3 (Network). Only IPsec protects all application traffic over an IP network. Using IPsec networks can ultimately secure applications from the IP layer. For comparison, other Internet security systems operate in the upper layers: Transport Layer Security (TLS) operates at Layer 4 (Transport Layer) and Secure Shell (SSH) at Layer 7 (Application layer).

What is HTTP?

HTTP stands for Hypertext Transfer Protocol. It’s the network protocol used to deliver virtually all files and other data ( called resources) on the Web. HTTP takes place through TCP/IP sockets.

A browser is an HTTP client because it sends requests to an HTTP server (Web server), which then sends responses back to the client. The standard (and default) port for HTTP servers to listen on is 80, though they can use any port.

What are “Resources”?

HTTP is used to transmit resources, not just files. A resource is some chunk of information that can be identified by a URL (it’s the R in URL). The most common kind of resource is a file, but a resource may also be a dynamically-generated query result, the output of a CGI script, a document that is available in several languages, or something else.

Structure of HTTP Transactions

Like most network protocols, HTTP uses the client-server model: An HTTP client opens a connection and sends a request message to an HTTP server; the server then returns a response message, usually containing the resource that was requested. After delivering the response, the server closes the connection (making HTTP a stateless protocol, i.e. not maintaining any connection information between transactions).

The format of the request and response messages are similar, and English-oriented. Both kinds of messages consist of:

  • an initial line
  • zero or more header lines
  • a blank line (i.e. a CRLF by itself)
  • and an optional message body (e.g. a file, or query data, or query output).

Put another way, the format of an HTTP message is:

<initial line, different for request vs. response>

Header1: value1

Header2: value2

Header3: value3

<optional message body goes here, like file contents or query data;

it can be many lines long, or even binary data $&*%@!^$@>

See the full HTTP article at HTTP Made Really Easy