I have a customer that has a Peplink Balance One running FW 7.1.0 Build 3433. Just recently they started failing PCI compliance and the results were stating because UDP port 500 was open relating to remote desktop. After taking a look I showed that I had remote user access turned on using L2TP with IPsec. I turned it off and the PCI scan then started passing. However, the user needs this remote user access turned on to get access to the network remotely. Is there by chance an updated firmware that fixes this issue?
I want to add on to this that I also received this PCI fail for the same reason, but I received a couple related fail notices that you might want to be aware of for other customers:
“Weak encryption ciphers, such as DES or 3DES, were identified as supported on this VPN device. These weak ciphers could make it easier for a context dependent attack to compromise the integrity of IKE sessions established with this device.”
“Diffie-Hellman Groups 1 to 4 are no longer considered safe for strong encryption. It is estimated that these groups have a security level of 80-90 bits which is no longer adequate to protect the encryption keys used during IKE phase 2. Furthermore, Group 5 (Modp-1536) has a security level of 120 bits which is slightly under to protect AES-128 encryption keys. Stronger groups have been designed for the Diffie-Hellman key exchange in RFC 3526.”
SSL Certificate is Not
Trusted (External Scan)
Port: tcp/32015
It was not possible to validate the SSL certificate, and thus it could not
be trusted. Users may receive a security warning when using this
service. This occurs because either the certificate or a certificate in its
chain has issues that prevent validation. Some examples of these
issues are, but not limited to, a certificate having expired, the
hostname does not have match the name on the certificate, or the
certificate is not signed by a well-known Certificate Authority (CA).
CVSSv2: AV:N/AC:M/Au:N/C:P/I:P/A:P
Service: generic_ssl
Evidence:
Subject: /OU=Domain Control Validated/OU=PositiveSSL/CN=captiveportal. peplink.com
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
Limited/CN=COMODO RSA Domain Validation Secure Server CA
Certificate Chain Depth: 0
Reason: The hostname on the certificate does not match any of the
hostnames provided to the scanner.
The issue I have here is that I have captive portal disabled on this device, so how the external scan is even picking up the captiveportal.peplink.com is confusing to me. Can anyone help me understand how this would be happening?
System Responds to SYN+FIN TCP Packets. Port: tcp/10
This device responded to a TCP packet with both the SYN and FIN bits
set. Such packets do not occur in typical network traffic, but can be
used by attackers to bypass the security rules configured in nonstateful
firewalls and establish connections with protected hosts.
CVSSv2: AV:N/AC:L/Au:N/C:N/I:N/A:N
Service: generic_tcp
Reference: VU#464113 - TCP/IP implementations handle unusual flag combinations inconsistently
Remediation:
Verify that stateful inspection has been implemented on the network to
protect this host from out-of-state attacks. Confirm with your vendor
that there are no known rule-bypass concerns with this device, and
that the software revision is current. You may additionally wish to
create specific filtering rules designed to drop or reject packets with
certain combinations of bits set in initial synchronization packets such
as SYN/FIN, and SYN/RST. Do not use routable IP space internally,
except within your DMZ.
Let us start discuss the PCI compliance by referring to the PCI compliance guide below:
Some of the settings you need to enable (as shown in the guide) before you start the scanning.
The above certificate is the default certificate for the device, you can upload your own cert to make sure the certificate used is compliance. Please refer to the screenshot below:
For #3, I’m still confused why an external WAN PCI scan would discover the captiveportal.peplink.com certificate when the captive portal feature is disabled on this device.
When VPN IPSEC is enabled, the PCI scan also finds the same certificate error. However, when VPN is disabled, the PCI scan does not find the certificate error. To me, both VPN and captiveportal would behave the same for these scans. If enabled, the scanner would see the generic certificates and give the error. If not enabled, the scanner shouldn’t give the error.
Re: 4. It is done by an external 3rd party. Trustwave. Edit: They scan our IP addresses connected to the Peplink device. There is no on-site testing.
I’m managing the Balance One directly from the device.
I took a closer look, and the “default certificate” for web admin uses the same captiveportal.peplink.com certificate name. I think that is why it appeared to be the captiveportal showing up/being scanned. I thought the certs were different for each service.
The 32015 port is related to speedfusion and PepVPN handshake port, and we are using PepVPN.
I want to give this a big thumbs up and more detailed request. More and more of our customers are failing PCI compliance scans. Some because of the cert, which we can fix but is a pain in the ass. Others just because it responds at all on these ports (32015 etc).
The pepwave is set to connect TO our central routers. So why is it responding to 32015 from random IPs?
My request is similar to the admin security=>web admin access control. Add ability to say “only respond to pepvpn requests from XXX subnets”. That way the port scan will find nothing.
