VNS3 Security Responses
Cohesive Networks LLC has never received a National Security Letter, FISA order, or any other classified request for user information.
GPSR Inquiries: GPSR-Compliance@Cohesive.net
LINUX Operating System “CUPS” Print Service RCE Compromise [26 September 2024] – CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177
*NO ACTION REQUIRED*
VNS3 is NOT VULNERABLE to the remote code execution via the port 631 printer service exploit.
Researcher Simone Margaritelli discovered a series of remote code execution risks in the “openprinting” system on Linux, which is deployed via a series of libraries to provide print services to Linux machine. Here are examples of the issues.
- CVE-2024-47176 | cups-browsed <= 2.0.1 binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a
Get-Printer-Attributes
IPP request to an attacker controlled URL. - CVE-2024-47076 | libcupsfilters <= 2.1b1
cfGetPrinterAttributes5
does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system. - CVE-2024-47175 | libppd <= 2.1b1
ppdCreatePPDFromIPP2
does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD. - CVE-2024-47177 | cups-filters <= 2.0.1
foomatic-rip
allows arbitrary command execution via theFoomaticRIPCommandLine
PPD parameter.
Even though VNS3 versions are not affected by this exploit it is good to remember deployment best practice.
- The VNS3 control plane port, TCP 8000, should not ever be open to the Internet, only via cloud security groups to specifically allowed source addresses such as your admin VPN, data center operations, or Cohesive remote support.
- The remote access port 22 should only ever be open to Cohesive’s remote support IP, and ideally, only opened via cloud security groups while an active support investigation is ongoing.
- In addition VNS3 default firewall does NOT allow any access to the print services port 631, nor are there any print service daemons running on VNS3.
VNS3 Network Platform uses a hardened Ubuntu Linux operating system and are built using the Elastic Server SBOM system. The base virtual images used to construct VNS3 Network Platform from 5.2.11 (5.x LTS) release through 6.2.9 and 6.6.8 (latest) have been reviewed and confirmed that these services are not installed nor running. Additionally the Elastic Server build logs have been reviewed to confirm that these services are not configured to run in the build process, and finally VNS3 instances have been reviewed as well to confirm no presence of the targeted services.
Detailed information here.
POTENTIAL REMOTE CODE EXECUTION BY UNAUTHENTICATED USER
*ACTION REQUIRED: Confirm control plane port 8000 access limitations*
*ACTION REQUIRED: Upgrade to new cloud image or request patching assistance*
POTENTIAL RCE by unauthenticated user
Four issues discovered via Trend Micro Zero Day Initiative ZDI-CAN-24160, ZDI-CAN-24176, ZDI-CAN-24177, ZDI-CAN-24178.
Corresponding CVE items: CVE-2024-8809, CVE-2024-8808,CVE-2024-8807,CVE-2024-8806
Cohesive has been working with customers to provide upgrades and patching assistance.
Fixes for these issues are included in releases 6.2.8+ and 6.6.7+.
The exploits are enabled by improperly parsed input. In two locations improperly parsed API input could allow for unauthenticated remote code execution, and in an additional two locations improperly parsed input could allow for authenticated administrator remote code execution. All require port 8000 access to be open to exploit the vulnerabilities.
A successful attack requires control plane TCP port 8000 access to a VNS3 controller which could allow an unauthenticated user to inject and execute arbitrary code. Users of the Wireguard(tm) VPN feature in 6.0.0-6.0.20 should contact Cohesive for immediate patching or upgrade assistance. No other versions of VNS3 require port 8000 to have broad access.
Affected Products and Version:
VNS3 4.6.1+ (EOL – Upgrade)
VNS3 5.0.x (EOL – Upgrade)
VNS3 5.1.x (EOL – Upgrade)
VNS3 5.2.0-5.2.11 (EOL – Upgrade)
VNS3 5.2.12 LTS (Upgrade or request patching support)
VNS3 6.0.0-6.0.20 (EOL – Upgrade)
VNS3 6.1.1-6.1.4 (EOL – Upgrade)
VNS3 6.1.5-6.1.9 (Upgrade or request patching support)
VNS3 6.2.0-6.2.7 (Upgrade or request patching support)
VNS3 6.6.0-6.6.5 (Upgrade or request patching support)
Mitigating Actions: Restrict port 8000 access to only your known “allow list” addresses. (Please include Cohesive Remote Support IP 54.236.197.84 if requesting patching assistance.)
Solution: Live patches are available from Cohesive Networks (successful patch validated by VNS3 version number appended with “-p1”) for any existing controller. Alternatively upgrading VNS3 to the following versions will eliminate exposure:
- VNS3 6.2.8 or later
- VNS3 6.6.7 or later
Questions? Open a ticket with Cohesive Networks (https://support.cohesive.net or email support@cohesive.net).
OpenSSH server side vulnerability “regreSSHion” RCE Compromise [1 July 2024] – CVE-2024-6387
*NO ACTION REQUIRED*
VNS3 is NOT VULNERABLE to the remote code execution via the OpenSSH server in this exploit.
Qualsys labs reported this vulnerability agains versions 8.5p1 and 9.7p1 of the OpenSSH server. VNS3 runs a security patched version 8.2p1 patch level 11, which is NOT vulnerable.
The compromise which could allow remote code execution on an affected host requires continuous, 4+ hour access to the TCP port (22 by default) on the affected host.
Even though VNS3 versions are not affected by this exploit it is good to remember deployment best practice.
- The VNS3 control plane port, TCP 8000, should not ever be open to the Internet, only via cloud security groups to specifically allowed source addresses such as your admin VPN, data center operations, or Cohesive remote support.
- The remote access port 22 should only ever be open to Cohesive’s remote support IP, and ideally, only opened via cloud security groups while an active support investigation is ongoing.
- In addition VNS3 default firewall does NOT allow any access to the OpenSSH port by default, rather admins must have enabled remote support via Web UI or API.
VNS3 Network Platform uses a hardened Ubuntu Linux operating system and are built using the Elastic Server SBOM system. The base virtual images used to construct VNS3 Network Platform from 5.2.11 (5.x LTS) release through 6.2.6 and 6.6.3 (latest) have been reviewed and confirmed that the OpenSSH server version is 8.2p1/patch11 and thus not affected. Additionally the Elastic Server build logs have been reviewed to confirm that no upgrade to a compromised version occurs in the build process, and finally VNS3 instances have been reviewed as well to confirm no presence of the compromised OpenSSH versions.
CVE-2024-6387 – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6387
Ubuntu Security Notice: https://ubuntu.com/security/notices/USN-6859-1
Other Information: https://www.qualys.com/
XZ Supply Chain Compromise [29 March 2024] – CVE-2024-3094
NOTE: VNS3 is NOT VULNERABLE to the supply chain compromise of the Linux XZ utility.
This severe compromise could allow remote code execution via a reverse shell capability built into the Linux “xz” utility and “liblzma” 5.6.0 or 5.6.1.
VNS3 Network Platform uses a hardened Ubuntu Linux operating system and are built using the Elastic Server SBOM system.
The base virtual images used to construct VNS3 Network Platform from 5.2.11 (5.x LTS) release through 6.2.2 (latest) have been reviewed and confirmed that the XZ and liblzma versions are 5.2.4, and thus not affected. Additionally the Elastic Server build logs have been reviewed to confirm that no upgrade of XZ occurs in the build process, and finally VNS3 instances have been reviewed as well to confirm no presence of the compromised XZ versions.
CVE-2024-3094 – https://www.cve.org/CVERecord?id=CVE-2024-3094
*NO ACTION REQUIRED*
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/