Cohesive VNS3 6.0 Beta3 is now available and free to use in AWS, Azure, and upon request. Get WireGuard(r) performance and encryption along with OIDC authentication, dynamic routing, global deployment capability, and integration to cloud and datacenter connectivity solutions today.
VNS3 Security Responses
Cohesive Networks LLC has never received a National Security Letter, FISA order, or any other classified request for user information.
Libcurl Vulnerability [11 October 2023] – CVE-2023-38546
NOTE: VNS3 is NOT VULNERABLE to the curl heap-based buffer overflow flaw CVE-2023-38545 which carries a severity rating of “high”.
VNS3 versions 6.0.0+ are vulnerable to the libcurl cookie injection flaw CVE-2023-38546 which carries a severity rating of “low”.
*NO ACTION REQUIRED*
CVE-2023-38546 – https://curl.se/docs/CVE-2023-38546.html
Cohesive has released updated images version 6.1.4 for all SKUs with latest security patch for CVE-2023-38546.
Libreswan restart vulerabilities [8 August 2023] – CVE-2023-38710, CVE-2023-38711, and CVE-2023-38712
The Libreswan project has published information about three recently patched vulnerabilities that can allow authenticated peers to cause the process to reset or crash through various methods. No remote code execution is possible via this attack. VNS3 only allows UDP500/4500/ESP in to a defined endpoint – so “prowlers” on the Internet cannot trigger these effects.
*NO ACTION REQUIRED*
CVE-2023-38710 – https://libreswan.org/security/CVE-2023-38710/CVE-2023-38710.txt
CVE-2023-38711 – https://libreswan.org/security/CVE-2023-38711/CVE-2023-38711.txt
CVE-2023-38712 – https://libreswan.org/security/CVE-2023-38712/CVE-2023-38712.txt
Cohesive will include the patched version in future releases of VNS3.
OpenSSL X.509 Email Address Variable Length and 4-Byte Buffer OverflowOpenSSL Critical Vulnerability [1 November 2022] – CVE-2022-3602 and CVE-2022-3786
Neither CVE-2022-3602 nor CVE-2022-3786 affect VNS3. VNS3 does not use the vulnerable versions of OpenSSL.
*NO ACTION REQUIRED*
CVE-2022-3602 – https://www.cve.org/CVERecord?id=CVE-2022-3602
CVE-2022-3786 – https://www.cve.org/CVERecord?id=CVE-2022-3786
OpenSSL 3.0.4 Heap memory corruption with RSA private key operation [5 July 2022] – CVE-2022-2274
CVE-2022-2274 does NOT affect VNS3. VNS3 does not use the vulnerable version of OpenSSL 3.0.4.
*NO ACTION REQUIRED*
CVE-2022-27666 – https://www.cve.org/CVERecord?id=CVE-2022-2274
Linux Kernel ESP Transformation Buffer Overflow [23 March 2022] – CVE-2022-27666
A vulnerability has been found in the Linux Kernel version 5.16.14 and earlier that can allow a buffer overflow of ESP protocol packets by an AUTHENTICATED administrator or partner/customer connected via AUTHENTICATED/NEGOTIATED IPsec tunnel. No unauthenticated remote buffer overflow, code execution, DoS, or other vulnerability is possible.
*NO ACTION REQUIRED*
CVE-2022-27666 – https://www.cve.org/CVERecord?id=CVE-2022-27666
Cohesive will include fixes in future releases of VNS3 when the Distro/OS updates make it into the kernel.
OpenSSL Security Advisory “Elliptical Curve Infinite Loop” [15 March 2022] – CVE-2022-0778
An exploit of the widely used OpenSSL library has been announced that in some situations can allow a denial-of-service attack. Remote code execution is NOT possible via this exploit.
LIMITED IMPACT ON VNS3 – NO IMMEDIATE ACTION REQUIRED FOR MOST USE CASES
CVE-2022-0778 – https://www.cve.org/CVERecord?id=CVE-2022-0778
OpenSSL Security Advisory Page – https://www.openssl.org/news/secadv/20220315.txt
REMEDIATION AND PREVENTION:
AT RISK: VNS3 deployments used today, that were INITIALLY deployed PRIOR to November, 2013.
If no new initialization of encrypted keyset has occurred since Nov 2013, then servers that have UDP 1194 open to the Internet are at risk. If the only VPN clients are “in-cloud” ensure port 1194 only open to cloud vpc/vnet to reduce exposure. Upgrade to VNS3 5.2.4 or contact Cohesive Support (support@www.cohesive.net) for a patch.
AT LIMITED RISK: VNS3 deployments using VNS3 version 3.0.4 (Nov 2013) or later for a “PeopleVPN” or road warrior use-case. A malicious user with a valid encrypted network credential (a “clientpack”) to the VPN could attempt to trigger a denial-of-service. Upgrade to VNS3 5.2.4 or contact Cohesive Support (support@www.cohesive.net) for a patch.
AT LIMITED RISK: VNS3 deployments using VNS3 version 3.0.4 (Nov 2013) or later for a machine-to-machine encrypted network. A malicious system administrator with root access to one of your servers could gain access to a valid encrypted network credential (a “clientpack”) and attempt to trigger a denial-of-service. While a system administrator with root access to your servers could do many things to interrupt service – this is a possibility for consideration. Upgrade to VNS3 5.2.4 or contact Cohesive Support (support@www.cohesive.net) for a patch.
AT NO RISK: VNS3 deployments using VNS3 3.0.4 (Nov 2013) or later that have NOT deployed any of the encrypted network credentials. As best practice, when not using the encrypted overlay do not have port 1194 open in cloud security groups/network acls. In addition, when not using the encrypted overlay, select the “Disable All” option on the “Clientpacks” page in the Web UI.
Cohesive has released updated cloud images as version 5.2.4 with latest security patches, including the patched version of OpenSSL.
Libreswan Security Advisory [12 Jan 2022] – CVE-2022-23094
The Libreswan project has published information about a recently patched vulnerability that can allow a denial of service attack (CVE-2022-23094). 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 – IF you have your cloud security group for the IPsec ports only open to your customer device(s) as recommended – then this specific exploit would not be of risk.
CVE-2022-23094 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23094
Libreswan CVE-2022-23094 Page – https://libreswan.org/security/CVE-2022-23094/CVE-2022-23094.txt
Vulnerable VNS3 versions: 4.11.4 – 5.2.2
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.
A new version of VNS3 has been released (Cloud Marketplace publishing process underway) that includes both the Libreswan patch and an update to the internal VNS3 Firewall that only allows inbound UDP 500, UDP 4500, and Protocol 50/ESP packets from configured IPsec Peer IPs to eliminate the vulnerability.
Log4Shell Vulnerability [10 Dec 2021] – CVE-2021-44228
Log4Shell vulnerability does NOT affect Cohesive VNS3 Platform. Apache Log4j is not included in the VNS3 Network Platform or the VNS3:ms Management System.
*NO ACTION REQUIRED*
Critical zero-day vulnerability in the Java logging library Apache Log4j is easy to exploit and enables attackers to gain full control of affected servers.
CVE-2021-44228 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
3rd party interpretation – https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/
Vulnerable VNS3 versions: NONE
Open Management Infrastructure Remote Code Execution Vulnerability [12 Sept 2021] – CVE-2021-38647
Recent Azure “OMI” agent vulnerability does NOT affect Cohesive VNS3 Platform.
*NO ACTION REQUIRED*
A recently discovered exploit allows unauthenticated remote code execution on servers (including Azure virtual machines) using the Azure OMI agent. Cohesive builds the VNS3 platform on top of a hardened Ubuntu Linux base. In order to be allowed in the Azure Marketplace we are required to run the “Azure Waagent” but do not install any other Microsoft software.
Cohesive has reviewed build logs and images confirming the agent is not present in any of our Azure releases.
The OMI agent uses tcp ports: 5986/5985/1270
VNS3 Platform users can easily confirm these ports are not in use using the Network Sniffer functionality in VNS3.
CVE-2021-38647 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38647
Microsoft Response – https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-38647
3rd party interpretation – https://arstechnica.com/information-technology/2021/09/security-researchers-at-wiz-discover-another-major-azure-vulnerability/
Vulnerable VNS3 versions: NONE
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/