Cohesive Networks has been helping our customers build robust transit networks on public cloud infrastructure since...
VNS3 LNKe: Creating Cloud-Agnostic Transitive Networks Without a lot of Fuss
read more
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
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.
Building Global Hybrid-Cloud Infrastructure Automation with Pipes and Python3
Building automation for foundational hybrid-cloud infrastructure deployments in hybrid cloud environments is hard. At Cohesive Networks we’ve helped our users build out networks that span datacenters, public clouds, IOT networks, even cell networks for bridging SMS communications. So we can find ourselves stitching together cloud infrastructure using different APIs in different clouds assuming different credentials etc. It can seem a little daunting. Now, If you’re in single public cloud, life’s a little bit easier: each cloud has their own deployment manager and Infrastructure as Code (IaC) templating system that more or less suffices. The complexity arises when you need to, say, build some infrastructure in AWS, then switch context and build in Azure, and switch back to AWS with state from the Azure infrastructure to continue building in AWS. The goal here is to step through an example architecture and simplify our deployment using pipes and python3.
The Hybrid-Cloud Architecture
So let’s run through a common hybrid-cloud architecture, break it down into discrete steps and see if we can’t simplify our lives.
Here’s a simplified architecture we see quite a bit: Account B in Cloud Y is providing connectivity (down and across) to Account A in Cloud X. Account A would like its applications to have secure access to any applications running on premise. At Cohesive we call the routing plane in Account B the “federation plane” and the whole network the “federation network”. It provides highly available connectivity to any new virtual private clouds (VPC) spun up in Cloud XYZ.
Automated VPC Cloud Construction
Ok, so let’s run through automating the construction of a new VPC in Cloud X that automatically has connectivity to on-premise applications. The steps for us look something like:
- Fetch network configuration for new VPC subnet (e.g. CIDR 10.1.0.0/16 with your favorite subnets)
- Create new VPC and virtual router/firewall (VNS3) for Account A in Cloud X
- Create fednet routing – routes for traffic “up” to 10.1.0.0/16.
- Create new VPC routing – routes to on-prem, traffic 10.0.0.0/16 to controller interface for routing traffic “down” to fednet
- Temporarily open API access for configuring VNS3 network routes and firewalls
- Connect new VPC with federation network by IPSEC peering controller in account A with federation network controllers
- Remove API access
- Teardown any configuration resources
Each step requires state from the previous step. This is really just a simple pipe: “echo parameters | fetch-network-config | create-new-vpc | …”. Ah, the beauty in simple ideas decades old. Each step accepts the previous step’s state, runs the step’s task, enriches the data with any new state and returns it. Now, I’ve always been partial to python for its ease of use and readability for things like this. Unfortunately, it doesn’t have native pipelining functionality. So let’s build it. Python3 also has some nice async features that we can take advantage for optimizing our automation.
The Python 3 Pipeline
A first pass at a simple pipelining function could be as simple as this:
I like to use python3’s new typing functionality because I think it makes for more maintainable code. Here it tells maintainers that a step is a tuple of length 2, where the first element is a string and the second is a callable function. We also copy the initial data so as not to mutate our caller’s data and then simply loop through our functions. So a pipeline function for our architecture might look like this:
So what’s going on here?
- We initialize some cloud clients that have permissions for provisioning resources in our cloud environments
- We define each step with a name (for readability and logging purposes) and a function. The function partial binds the parameters passed (template) to the function provided as the first argument. You’ll see each step can target whatever cloud we want using whatever IaC templates we like and the state will be passed through. In fact, each step can do anything so long as it respects the function signature expected (ie. it accepts and returns a dictionary).
A Little Optimization
This works quite nicely and it’s very simple. You might notice that some steps could perhaps be combined or run concurrently. Python3’s asyncio makes that quite easy:
Our new pipe function has a couple changes:
- It now accepts different kinds of steps as indicated by the Union typing parameter. Our pipe now accepts a step that provides a list of functions rather than just one. Using asyncio.gather we can run each sub-step concurrently (each sub-step must implement the async/await paradigm )
- We also updated our step functions to return a dictionary that has an optional “outputs” key for passing along in the pipe.
Add thats it. Pretty minor changes to take advantage of steps that can be run concurrently. Here’s what our deployment pipeline looks like now:
We’ve found this approach simple and effective. I’ll end with putting out a feeler: is there any interest in an open source python3 library for hybrid-cloud deployment automation? It would be purposefully simple and pluggable, adopting only a few powerful idioms like a pipeline. Let us know!
A look under the hood: VNS3 networking devices
As you’ll remember from networking foundations (4 things everyone should know about network layers), routers, switches, firewalls, and port filtering all happen between layers 4-7 of the OSI layer model.
Quick, here’s a short video on what devices work at each layer:
One thing we like to brag about with VNS3 is that it is a layer 4-7 networking device. What does that mean? How can that be? VNS3 is software, and acts as 6 devices in 1:
- router,
- switch,
- SSL/IPSec VPN concentrator,
- firewall,
- protocol distributor,
- scriptable network function virtualization
VNS3 is a network appliance – or virtual, remember it’s software. With a software-based networking devices you can build those function on top of cloud-provider devices, like AWS security groups or Azure network security groups. Remember that defense in depth !
How does it work? What’s it made out of??
VNS3 builds on core VPN concepts but allows more customer control with an “overlay network.” An overlay network is a computer network built on top of another network. Nodes in an overlay can be virtual or logical links. VNS3 adds control over topologies, network addressing, encrypted communications, and network protocols.
Unlike other VPNs, VNS3 also acts like a virtual router, switch, firewall, VPN concentrator, protocol redistributor, and NFV container. VNS3 allows many, many networking use cases including:
- application layer firewall with custom rules and hashings
- connecting both NAT-T and Native IPsec endpoints on the same endpoint
- Layer 2 Bridging over GRE as well as GRE tunneling over IPsec
- customizable, flexible networks with Docker containerized network services
- Trend Micro Deep Security central management agent
VNS3 Controllers are virtual machines (VMs) that act as a VPN gateway for the other virtual machines in the same cloud infrastructure. VNS3 synchronize between each other using RabbitMQ ( a little thing we put together a while ago ). VNS3 has a web-based UI and traditional Linux system command line interface (CLI). The VNS3 API uses a Ruby script and Ruby language binding. Everything else is a secret. Seriously, we’ve got a patent.
Put it all together: VNS3 devices
Advanced firewall rules with VNS3
Part 2 of firewall rules with VNS3
Check out part 1 for all the overview parts.
Quick review:
VNS3 Firewall features are controlled using IPTables syntax. For more information see http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http:// www.thegeekstuff.com/2011/06/iptables-rules-examples/
The order of rules matter.
If your customer rules don’t reject a packet, it will be allowed by default. However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.
NATing:
Network address translator (NAT) can act as an intermediary agent on behalf of clients. The real originating IP address might be masked from the server receiving a request. A common practice is to have a NAT mask a large number of devices in a private network. Only the “outside” interface(s) of the NAT needs to have an Internet-routable address.
Firewall Rules – NAT
Most public clouds now provide VLAN isolation, a critical element of the defense in depth security approach. VLAN isolation also creates the need for additional capabilities beyond the basic compute and networking functions for application owners.
“NATing” allows the machines in a VLAN to use the VNS3 Controller as a gateway to services on the Internet, with all VLAN machines sharing the Controller’s public IP address.
NATing in public cloud uses the same behavior used in your home or office, where many devices can access the Internet via one shared public IP address. When a VLAN device accesses the Internet, its return traffic is routed to it.
Basically, VNS3 lets you use your cloud VLAN just like you treat your home or office network, isolated from inbound requests for service, but allowing most outbound service requests.
Simple Syntax
MACRO_CUST -o eth0 -s 172.31.1.0/24 -j MASQUERADE
In this example your VNS3 Controller is in a VLAN subnet with a network from 172.31.1.0-172.31.1.255. Many clouds with VLAN capabilities map a public IP to the private IP on eth0 via DNS.
Here we are telling the VNS3 Controller to “masquerade” for traffic coming from that subnet out to the Internet and then return the response packets to the requesting machine.
Firewall Rules – Port Forwarding
With AWS VPC, your can configure your cloud servers to not be visible and accessible from the Internet. AWS assigns a standard, automatically-assigned public IP , but we do not recommend relying on the automatic IP because you will not retain the same IP address if you shut down the instance. Rather, you should assign an Elastic IP to put the server on the Internet.
What if you want to be able to access one of the machines (for example like you might do on your home network) from the Internet? This is where port forwarding comes in.
A common use case would be using a Windows Remote Desktop on one of your cloud servers, as the “jump” box for then remoting to all the other cloud servers in your VPC. VNS3 lets you do this with your VPC, just like you could for your home or office network, allowing specific traffic, from a specific source, on a specific port to be “forwarded” on to another machine.
Simple Syntax
MACRO_CUST -o eth0 -s 10.199.1.0/24 -j MASQUERADE
Using the same example network, assuming a source network public IP of 69.69.70.70 from which the RDP client is running, do the following:
- NATing needs to be enabled for port forwarding to work
- Specify the port to be forwarded, in this case “RDP” or 3389
- Specify the source network address, here 69.69.70.70/32
- Specify the machine for port 3389 traffic, here 10.199.1.130 using the “–to” syntax
- Use the “-j DNAT” syntax to specify destination network address translation.
Firewall Rules – Netmapping
Netmapping allows you to create IPsec tunnels to imaginary IPs on the VNS3 side of the connection and use the VNS3 firewall to map all traffic to/from the imaginary IP, to the actual host on your cloud side. This is extremely useful in situations where a connecting party has an address overlap with your Overlay or VLAN subnet.
Example
Remote subnet 10.10.10.0/24
Local Server the Remote wants to access: 172.31.10.50
Customer will not connect their LAN (10.10.10.0/24) to a private network Allocate an EIP to your account but DON’T associate: 23.23.23.23.
Build an IPsec the tunnel from 23.23.23.23/32 to 10.10.10.0/24
Simple Syntax:
PREROUTING_CUST -i eth0 -s 10.10.10.0/24 -d 23.23.23.23/32 -j NETMAP –to 172.31.10.50/32
POSTROUTING_CUST -o eth0 -s 172.31.10.50/32 -d 10.10.10.0/24 -j NETMAP –to 23.23.23.23/32
If the Local Subnet is a VLAN and not the Overlay Subnet add the following forward rule:
FORWARD_CUST -j ACCEPT
Copy Traffic to a Device
With the addition of the Docker-powered application container system there are scenarios where you might want to push a copy of the traffic from the eth0 or tun0 VNS3 interface to a particular IP. The obvious use-case is copying traffic to the Cohesive Utilities Container where you can do things like run tcpdump or iftop.
Example:
I want to copy all tun0 (Overlay Network) traffic to my Network Utils Container running on the VNS3 Controller on the Docker network at 172.0.10.2.
Simple Syntax:
MACRO_CUST -j COPY —from tun0 —to 172.0.10.2 —bidirectional
SNMP Support
VNS3 now supports a number of industry standard MIBs for use from monitoring system doing SNMP polling. We do not currently support any SNMP traps.
VNS3 SNMP support is enabled through the firewall. In the future we will provide API calls and user interface to provide more control of the SNMP experience.
To enable access to the SNMP information add the following rule to firewall using a source address from your network (either your public IP, or an internal IP available to the Controller via IPsec or Clientpack). There is no SNMP authentication in this beta. An example rule would be
INPUT_CUST -p udp -s 69.69.70.70/32 –dport snmp -j ACCEPT
(where 69.69.70.70 is your network’s public IP address).
On your SNMP monitoring system:
- Use SNMP v1c or v2
- Community string of “vns3public”
- The access to the SNMP information is “read only”
You should then be able to use a utility like “snmpwalk” to test:
snmpwalk -v 1 -c vns3public -O e <vns3_manager_public_ip>
Want to see something cool? Let’s add 10,000 firewall rules at once!
If you have trouble with the video player below, watch the video on YouTube: https://youtu.be/N-c3GyGP6qk
Firewall Overview with VNS3
This is part 1 of an overview of firewall rules and capabilities with VNS3. Stay tuned for more advanced VNS3 firewall scenarios: Network Address Translation (NAT-ing), Port Forwarding, Netmapping, SNMP Support, and Copying Traffic to a Device.
A Super fast Firewall Overview
Firewall = network security system that monitors and controls the incoming and outgoing network traffic based on a set of security rules.
Firewalls act as a barrier between a trusted, secure network and another network, like the public Internet
2 Types of Firewalls:
- network firewalls: protect the perimeter of a network by watching traffic that enters and leaves
- host-based firewalls: protect individual devices regardless of the broader network
IP addresses and firewalls
You can use a firewall to control access to a server or network, or to selectively tailor a client’s response to each request for criteria.
Firewalls examine each packet in TCP/IP traffic. Firewalls determine whether to drop packets or forward packets to the destination. Packets contain 3 key sections: IP header, TCP / UDP header, and data (payload).
NAT Firewalls, IP address translation, and NAT-ing
Network address translator (NAT) can act as an intermediary agent on behalf of clients. The real originating IP address might be masked from the server receiving a request. A common practice is to have a NAT mask a large number of devices in a private network. Only the “outside” interface(s) of the NAT needs to have an Internet-routable address.
Commonly, the NAT device maps TCP / UDP port numbers from public networks to individual private addresses on the masqueraded network. In a typical NAT, only the valid IP address is assigned to the firewall. All other device IP addresses are behind firewall, and their internal IP addresses are only valid on the private network.
Home networks scenario:
NAT functions are usually implemented in a residential gateway device, typically one marketed as a “router”. In this scenario, the computers connected to the router would have private IP addresses and the router would have a public address to communicate on the Internet. This type of router allows several computers to share one public IP address.
When a device on the private network needs to communicate with the outside world, the device sends its request to the firewall. The firewall then places the request on behalf of the device that actually made the request. When the response to the request comes back, the request arrives at the firewall, and then the firewall sends the response to the appropriate computer on the private network.
Firewalls in VNS3
VNS3 acts as an application-layer firewall. It’s a great tool to layer your firewall security on top of lower-level firewalls like AWS Security Groups or Azure Network Security Groups. VNS3 is a layer 4 – 7 firewall for your cloud based application. We like to highlight how it allows you more control over your cloud deployments – Only you can control your VNS3 firewall rules.
Set up that VNS3 Firewall
Once you set up and configure your VNS3 instance, add firewall rules to allow or reject packets.
Navigate to Connections > Firewalls to enter firewall rules. Click Save and Activate.
ta da!
Notes on VNS3 Firewall syntax
VNS3 Firewall features are controlled using IPTables syntax. For more information see http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http:// www.thegeekstuff.com/2011/06/iptables-rules-examples/
The order of rules matter – rules are applied from top to bottom until the first match. If no match is found, the packet is allowed to continue on.
In addition to the standard security and firewall features of VNS3 you can create your own rules to restrict traffic to and through the VNS3 Controller. Write a specification for a packet to match, then specify what to do with the packet.These are “customer” rules and are applied as appropriate in the overall firewall rule structure on the VNS3 Controller.
If your customer rules don’t reject a packet, it will be allowed by default. However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.
VNS3 Firewall examples: the basics
Drop all packets from 1.1.1.1 to 2.2.2.2:
INPUT_CUST -s 1.1.1.1 -d 2.2.2.2 -j DROP
Drop all traffic from 192.168.3.0/24 (entire subnet) except 192.168.3.11:
INPUT_CUST -s 192.168.3.11/32 -j ACCEPT
INPUT_CUST -s 192.168.3.0/24 -j DROP
Drop tcp traffic from 172.31.1.1 on port 8000 (Stop overlay clients from using the overlay IP of 172.31.1.1 with port 8000).
INPUT_CUST -p tcp -s 172.31.1.1/32 –dport 8000 -m state –state NEW,ESTABLISHED -j DROP
INPUT_CUST -p tcp –sport 8000 -m state –state ESTABLISHED -j DROP
VNS3 Firewall Warning
The VNS3 firewall allows customers complete control of the INPUT, OUTPUT, FORWARDING, PREROUTING and POSTROUTING behavior of traffic as it first enters the VNS3 Controller and as it exits the VNS3 Controller.
The VNS3 internal firewall is still there to “protect” the internal mechanisms of VNS3, however, customer rules can be created that have undesirable effects. Essentially rules that ACCEPT or REJECT/DROP all traffic are likely to create a device that is un-reachable or one that is too permissive in accepting traffic.
Customer rules are evaluated and if there is not a match in the _CUST chains, then they flow through into the interior VNS3 chains which are quite restrictive. Accepting all traffic prevents most of the interior rules from being evaluated which might block unsafe traffic. Blocking all traffic prevents most of the interior rules from being evaluated which accept necessary traffic such as the API and WebUI management utilities. (Blocking port 8000 from all traffic will make the VNS3 instance un-manageable.)
Do not have rules of either of the following forms:
INPUT_CUST –dport 8000 -j REJECT
INPUT_CUST -j REJECT
INPUT_CUST -j ACCEPT
Up next, we’ll look at more advanced VNS3 firewall scenarios including: Network Address Translation (NAT-ing), Port Forwarding, Netmapping, SNMP Support, and Copying Traffic to a Device.
Recent Comments