IPv6, Secure and Private AI are both upon us, and Cohesive Networks is delivering into those areas with the same practical approach we have used for Public and Private Cloud all these years.
Moving to IPv6 – herein lies madness (Part 1)
read more
The Enterprise and WireGuard
WireGuard® at its core is a lightweight, low code, VPN tunneling protocol that optimizes for speed, security and ease of configuration. However, extended business functions needed for enterprise usage are left out of its code base by design. This non-opinionated approach allows third parties to develop novel methods that best fit enterprise needs and styles.
Examples of Enterprise needs are:
- Key (re)generation and distribution for both human users and machine-to-machine networks
- RESTful API for integration to in-house systems and external services
- Uniform access to encrypted tunneling via regional or global clusters
- Dynamic routing so devices on the WireGuard network learn about network paths as they come and go
- Failover support allowing clients to migrate servers in the event of maintenance or outages
- Integration to security platforms (Firewalls, WAFs, IDS/IPS)
- Integration to other “tunneled” paths (IPsec, GRE, VXLAN, cloud direct connects, etc..)
- Integration to “legacy” monitoring tools like SNMP
- Integration to “modern” monitoring tools like Datadog and Sumologic
- Integration to legacy authentication (Active Directory)
- Integration to modern authentication (OAuth / OpenID, MFA, etc..)
- AND more!
Cohesive is working to make the WireGuard protocol a first order citizen in our VNS3 Network Platform with a focus on many of these extended capabilities.
Enterprises will need methods to securely store and distribute keys to human and machines. Authenticated REST APIs allow automation frameworks to tag and place keys where needed in a distributed computing environment. Self-service web portals give end users access to allocated keys for their various devices. Administrators and intrusion detection systems need the ability to revoke keys when compromise occurs.
Not all tunneling systems and their keys are the same. Many companies employ encrypted overlay networks, in cloud and between their compute nodes in order to satisfy regulatory requirements and gain network visibility. For automated machine-to-machine communications, public/private key pairs are all that is required, whereas with “people VPN” scenarios added authentication factors are needed.
In the dynamic world of cloud networking and remote work, private networks are now fluid, meaning that network address ranges are added and removed, as new networks and subnets come on line or are decommissioned. In order for systems to communicate they need dynamic route updates providing up-to-date paths through interconnected transit networks.
These encrypted tunneling systems are used to take the enterprise, its customer and partners to, through, and across clouds. This requires the WireGuard feature called “Allowed IPs” that acts as both ACL and route directives to be integrated. In Enterprise WireGuard use-cases, the “Allowed IPs” don’t come from a configuration file, they will be dynamically and seamlessly integrated to the broader systems routing and ACL policies. communications in the enterprise. Companies need the ability to filter and direct traffic at ingress and egress points in cloud networks.
WireGuard is fast becoming an essential operating system and developer tool, and Cohesive Networks believes it’s on its way to being an essential building block for creating robust, enterprise-ready network solutions.
“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.
News Roundup: Week of Feb 21, 2022
U.S. Cyber Officials Issue Official Warning Against Potential Russian Cyber Attacks
During a call this Monday, FBI and DHS cyber officials urged government agencies “to look out for signs of Russian activity on their networks” as a result of the evolving Ukraine crisis. According to Yahoo: “federal officials also urged those on the call to dramatically lower their threshold for reporting suspicious activity.” Citing “an uptick in Russian scanning of U.S. law enforcement networks” as well as “in Russian disinformation and misinformation about Ukraine,” cyber officials urge increased care and caution with links and communications as the crisis progresses.
IBM Opens Cyber Security Hub in India
IBM recently announced the opening of their first IBM Security Command Center in the Asia Pacific region. The center hopes to provide a cybersecurity incident response plan for enterprise customers with deployments in the region, as well as “a fully immersive, interactive, and experiential learning facility.” IBM plans to use simulations and experiential training to help enterprises protect themselves from cyberattacks. IBM promises that by co-locating this training center with their X-Force Command Center, IBM’s Security Operations Center, both live practice and training for cyber security precautions will benefit immensely.
Microsoft Brings Cloud Security to GCP
Yesterday Microsoft announced the release of Microsoft Defender for Cloud for Google Cloud Platform, making Microsoft the first major cloud provider to offer security solutions in all major cloud platforms. The offering from Microsoft boasts Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) across both containers and servers. According to the release, GCP deployments of Microsoft Defender for Cloud will come “with out-of-box recommendations that allow you to configure GCP environments in line with key security standards like the Center for Internet Security (CIS).” Microsoft is also emphasizing the necessity of Zero Trust Management and event log management in cloud environments with two more ‘upgraded’ cloud security offerings.
Distributed Hybrid MultiCloud Mesh with VNS3 and LNKe
As cloud adoption continues to ramp up in 2022, with Gartner projecting another 21.7% growth in cloud spend this year, companies are maturing beyond their initial workload migrations to single cloud vendors. Whether to create resiliency due to the now not so uncommon major outages we have seen in the past few years, to tailor their many application environments to changing business requirements, or to migrate to new cloud vendors whose offering is the best fit. However, in order to realize these opportunities, companies need a consistent network layer that is uncoupled from any one cloud vendors specific dependancies. No matter which cloud you choose, achieving this goal requires utilizing third party network solutions. Such a solution should ideally facilitate connectivity to data-centers, remote users, and IOT devices as well.
Cohesive Networks VNS3 cloud edge security controllers can create the backbone across all of your public cloud vendors in an easy to manage and secure mesh, with LNKe connecting all of your virtual private networks. This gives you a fully transitive network across all of your cloud real estate, running at performative speeds with built in failover and self healing mesh capabilities. Granular IPSec cloud edge configurations allow you to connect corporate data centers, partner networks and vendor access, regardless of their hardware. Policy enforcement is consistent across the network and has been simplified for ease of management. With our comprehensive firewall you can easily define people, groups and network objects to allow your remote workforce to securely connect at the edge closest to their physical location. In short, with VNS3 and LNKe, you can create a full network mesh consistent with your needs that can grow to anywhere that you need to be and scale with your deploments.
Please reach out to the Cohesive Networks sales and solutions team at contactme@www.cohesive.net to further the discussion with any interests that you may have. We are always happy to help.
News Roundup: Week of Dec 26, 2021
Could Continuing AWS Outages Give Rise to Distributed Cloud Deployments?
Widespread disruption of high-use internet services was recently experienced as a result of the third AWS outage in the span of a month. AWS reported this latest disruption was caused by “a power outage at a data center in Northern Virginia” which saw giants like Hulu and Slack offline for about two and a half hours. A recent article from The Washington Post suggests that having a cloud deployment with a singular, critical point of failure creates opportunities for widespread outages, in a world where distributed cloud deployments can offer you some protection from these outages. As “the cloud’s increasing intricacy and demands” continue to increase, and companies continue to migrate and develop in the cloud, the potential for outages caused by the “over-centralization” of infrastructure into heavily-used AWS regions also increases.Azure App Service Insecurity Exposing Source Code Since 2017
A recently discovered insecurity in the Azure App Service has “exposed the source code of applications written in PHP, Python, Ruby, and Node” and has been prevalent since September 2017. SC Magazine purports that this security flaw was first widely reported to the public by The Wiz on Oct. 7, 2021, and Microsoft has since updated it’s security recommendations document and mitigated the default behavior that caused this issue. Further research suggests that this vulnerability was likely not a well-kept secret and would have been widely exploited during the purported four year window of this vulnerability. We recommend double-checking your deployments against these new recommendations to ensure that your source code isn’t vulnerable.Security Attacks Likely to Continue to Increase in 2022
2020 and 2021 have been marred by an increase in the commonality and sophistication of security attacks on companies as we all navigate the uncharted waters of remote work, and address the new connectivity and security concerns that have surfaced as a result of this necessary transition. A recent article from Bloomberg law suggest that some of the most damaging attacks have targeted backbone systems and solutions, such as the Microsoft Exchange software attacks that affected many companies in 2021. Alarmingly, many of the “exploits used in the first quarter of 2021 are still being used today” which only serves to create added pressure on both the solutions providers and companies that build critical systems upon such backbones solutions. These attacks are complemented by more ‘traditional’ phishing attacks, “which remains one of the highest-volume types of vulnerabilities” across all business sectors. Having proper security procedures and communication channels in place is more important than ever, and the criticality of such considerations will only increase as we move into 2022.JEDI Becomes JWCC With Decision Target of Q3 2022
In the wake of four years of legal challenges and congressional inquiries, The JEDI contract has been replaced with a new framework, the Joint Warfighter Cloud Compatibility (JWCC), “from which to deliver commercial cloud services to Defense personnel.” The Pentagon “issued formal solicitations for JWCC” to AWS, Microsoft, Google, and Oracle, effectively leveling the playing field for the biggest US cloud providers. According to Nextgov “The Pentagon plans to make JWCC awards in the third quarter of fiscal 2022” which could bring some interesting infrastructure developments from these cloud providers.
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://
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=90sVNS3 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.
How to Replace your NAT Gateway with VNS3 NATe: Part II
In part I of our NATe post we discussed economic advantages to replacing your AWS NAT Gateways with Cohesive Networks VNS3 NATe devices. We also walked through how to deploy them. In this follow up post I want to dig in a little into the some of the incredibly useful capabilities that VNS3 NATe provides.
In part I we discussed how to replace your current NAT Gateway. One of the steps in that process was to repoint any VPC route table rules from the NAT gateway to the Elastic Network Interface (ENI) of the Elastic IP (EIP) that we moved to the VNS3 NATe ec2 instance. This was done for consistency so that if you had any rules in place that referenced that IP, you would remain intact. Unfortunately, due to the mechanics of AWS NAT Gateway, you can not reassign its EIP while it is running. So we had to delete it in order to free up the EIP. This part of the operation introduced 15 to 30 seconds of down time. With VNS3 NATe devices you can easily reassign an EIP without the need to delete an instance. Our upgrade path is to launch a new instance and move the EIP to it. Since we set our VPC route table rules to point to the ENI of the EIP, our routes will follow.
Another powerful feature of VNS3 NATe is the container plugin system. All VNS3 devices have a plugin system based around the docker subsystem. This allows our users to inject any open source, commercial or proprietary software into the network. Coupled with the VNS3 comprehensive firewall section, this becomes a versatile and powerful feature. In the case of a NAT device, there are some serious security concerns that can be addressed by leveraging this plugin system.
Suricata, the Network Intrusion Detection and Prevention System (IDS/IPS) developed by the Open Information Security Foundation (OISF) for the United States Department of Homeland Security (USDHS), is a powerful addition to a VNS3 NATe device. Modern day hacking is all about exfiltration of data. That data has to exit your network and the device that is in path is your NAT device. Additionally malware will often attempt to download additional software kits from the internet, this traffic also traverses through your NATe device. In both of the these scenarios Suricata has powerful features to analyze your traffic and identify suspicious activityand files. You can find directions for setting up Suricata on VNS3 here:
https://docs.cohesive.net/docs/network-edge-plugins/nids/
Additionally, Cohesive Networks has developed a Brightcloud Category Based Web Filtering Plugin. Brightcloud have created a distinct list of categories that all domain names have been divided into. The plugin takes advantage of this categorization in three ways:
- An allow list – A comma separated list of categories that are allowed. The presence of the allow_list.txt will block all traffic, only allowed categories will be permitted.
- A deny list – A comma separated list of categories that are denied. The presence of the deny_list.txt will allow all traffic, only the specified categories will be forbidden.
- An exclusion list – A comma separated list of URLs that are not to be considered by the plugin.
These are just a few examples of software plugins that can run on VNS3 NATe. Others that will work are Snort, Bro (Zeek), Security Onion. Our Sales and Support teams are always happy to assist you in determining the right approach and assisting you with your implementation.
Recent Comments