We’re thrilled to announce our 2021 website, and we wanted to take the opportunity to explain our design choices and some of the decision making that is leading us forward.
VNS3 Security Responses
Cohesive Networks LLC has never received a National Security Letter, FISA order, or any other classified request for user information.
VNS3 Vulnerability [7 Aug 2020] – CVE-2020-15467
The vulnerability allows an AUTHENTICATED administrator to gain access to the VNS3 host operating system. This vulnerability was discovered by researchers at Fireeye/Mandiant. It is applicable to all VNS3 4.x versions prior to 4.11.1.
*NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES*
The authenticated user has complete control of the VNS3 device. They can reboot it, halt it, use the firewall to coerce, change, inspect or even redistribute traffic – as VNS3 is a network device for those very purposes. Some network device providers provide shell access to their devices – something Cohesive does not do – as we believe VNS3 being a sealed appliance ensures consistency and integrity of performance. Through our plugin system and customer controlled plugins we allow many of the capabilities of host access – with reduced risk of an improper change to the VNS3 appliance.
CVE-2020-15467 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15467
Vulnerable VNS3 versions: 4.0 to 4.9.2
REMEDIATION and PREVENTION:
- Upgrade to VNS3 4.11.1 which has been fixed for this vulnerability (as well as attempts at similar exploits both in Cohesive code and underlying library code).
- Contact Cohesive to patch in-place VNS3 appliances via remote support operation. Customers with 24×7 support contracts will be given priority.
- Use VNS3 Administrator sign-on controls in VNS3 4.9.2+. One of the feature areas we have focused on in the last several releases is Administrator login and logging. VNS3 appliances can now be pointed at an LDAP directory, Active Directory or Google Gsuite account for authentication of its Administrators, with that information also captured in internal logging as Administrators take actions. This can certainly provide insight into the actions and behaviors of your VNS3 Administrators.
While this does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
Libreswan Security Advisory [11 May 2020] – CVE-2020-1763
The Libreswan project has published information about a recently patched vulnerability that can allow a denial of service attack (CVE-2020-1763). No remote code execution is possible via this attack, the vulnerability could allow an external third party to crash the VNS3 IPsec subsystem by sending repeated malformed IKEv1 packets on UDP 500.
*NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES*
CVE-2020-1763 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-1763
Vulnerable VNS3 versions: 4.4.0 to 4.9.1
Not Vulnerable: 4.3.11 and earlier & 4.9.2 and later
REMEDIATION and PREVENTION:
Limiting UDP 500 and UDP 4500/ESP protocol 50 inbound access to the VNS3 controller instance from only those remote addresses needed for the IPsec VPN connections eliminates exposure to this vulnerability. Use the VNS3 firewall, cloud hypervisor firewall (e.g. Security Group) and/or cloud ACL to prevent exposure.
While the potential denial of service does represent a vulnerability, the attack vectors for VNS3 deployments are limited if at all present. Vulnerabilities of any kind can be controlled by implementing a layered/defense in depth security approach as defined below.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- Clientpack credentials should only be distributed known and trusted devices.
- Any unused clientpack credentials should be disabled via UI or API to prevent unauthorized use.
- Clientpacks credentials should be regenerated when a device that was using that credentials is deprovisioned.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulated (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- Make sure TCP port 8000 is restricted to only the IPs that are required to admin your VNS3 Manager(s) via the cloud hypervisor firewall rules (Security Groups, Cloud Service, etc.) and reinforced with similar restrictions via the VNS3 Firewall.
- Disable SSL 3.0 in your browsers being used to administer the VNS3 Managers. Here is information on how to disable on the most popular browsers:
- For those of you operating in AWS, new AMIs have been built, deployed and shared with your accounts. Updated AMIs are listed below. Customer using and licensed for 2.x-3.0x use the following AMIs:
Region | AMI ID |
---|---|
US-East-1 | ami-8876c2e0 |
US-West-1 | ami-038d8546 |
US-West-2 | ami-f5db98c5 |
EU-West-1, | ami-aa9435dd |
AP-Southeast-1 | ami-ae496efc |
AP-Southeast-2 | ami-a1dbb89b |
AP-Northeast-1 | ami-7f9fb67e |
SA-East-1 | ami-a918b2b4 |
Gov Cloud | ami-8d2640ae |
- Customers using and licensed for 3.5x use the following AMIs (Note: only EBS-backed Images if you have previously received and agreed to the EBS Disclosure and Agreement):
Region | AMI ID (Instance Store) | AMI ID (EBS) |
---|---|---|
US-East-1 | ami-5a54e032 | ami-8071c5e8 |
US-West-1 | ami-39848c7c | ami-f78e86b2 |
US-West-2 | ami-bde7a48d | ami-5fda996f |
EU-West-1 | ami-3e9e3f49 | ami-2e963759 |
AP-Southeast-1 | ami-ae5473fc | ami-be486fec |
AP-Southeast-2 | ami-4dd8bb77 | ami-37dab90d |
AP-Northeast-1 | ami-2d7f572c | ami-8f93ba8e |
SA-East-1 | ami-a91cb6b4 | ami-b919b3a4 |
Gov Cloud | ami-f72640d4 | ami-b919b3a4 |
- For those of you operating in AWS, new AMIs have been built, deployed and shared with your accounts. Updated AMIs are listed below. Customer using and licensed for 2.x-3.0x use the following AMIs:
Region | AMI ID |
---|---|
US-East-1 | ami-c66cd9ae |
US-West-1 | ami-cbdcd48e |
US-West-2 | ami-938ecda3 |
EU-West-1, | ami-c4e948b3 |
AP-Southeast-1 | ami-c06d4a92 |
AP-Southeast-2 | ami-7bf49741 |
AP-Northeast-1 | ami-251f3624 |
SA-East-1 | ami-6b0aa076 |
- Customers using and licensed for 3.5x use the following AMIs (Note: only EBS-backed Images if you have previously received and agreed to the EBS Disclosure and Agreement):
Region | AMI ID (Instance Store) | AMI ID (EBS) |
---|---|---|
US-East-1 | ami-664df80e | ami-1c7bce74 |
US-West-1 | ami-2fd2da6a | ami-a3ddd5e6 |
US-West-2 | ami-8996d5b9 | ami-058dce35 |
EU-West-1 | ami-9cf253eb | ami-66ed4c11 |
AP-Southeast-1 | ami-766a4d24 | ami-546d4a06 |
AP-Southeast-2 | ami-7ff89b45 | ami-4df49777 |
AP-Northeast-1 | ami-93e9c092 | ami-3b1e373a |
SA-East-1 | ami-2308a23e | ami-f10aa0ec |
- When possible use cloud VLANs like those available in AWS VPC, Azure, Google Compute, and others.
- Use network ACLs and Hypervisor Port Filtering (like AWS Security Groups)
- Ideally a VNS3 Manager should only have the following port assignments:
- TCP Port 8000 open to only your operations center and as needed to Cohesive Networks’ support address
- TCP 22 only open as needed to Cohesive Networks’ support address
- UDP 500 only open to specific partner IPsec endpoints for IKE/Phase1 connectivity
- ESP/Protocol 50 only open to a specific partners IPsec endpoint address when using native IPsec
- UDP 4500 only open to specific partner’s IPsec endpoint address when using encapsulted (NAT-T) IPsec
- UDP 1195-1202 only open as documented to other VNS3 managers in a topology.
- UDP 1194 only open to VNS3 clients IP addresses or subnet masks as required.
- UDP SNMP port only open to your operational system making SNMP polling requests.
- To further secure your topologies we recommend using the VNS3 Network Firewall as well as host filtering on your cloud servers.
- OpenSSL Notification: https://www.openssl.org/news/secadv_20140407.txt
- TechCrunch Article: http://techcrunch.com/2014/04/07/massive-security-bug-in-openssl-could-effect-a-huge-chunk-of-the-internet/