SSH SSL Issues Reported From Vulnerability Assessment

[almay]

The results of a vulnerability assessment is reporting the following issues with PAN firewall with version 7.1.6.  Is this due to the settings in the decryption profile?  Any direction would be helpful.  Thank you.

CVE	NAME	DESCRIPTION	SOLUTION
	SSL Medium Strength Cipher Suites Supported	The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64 bits and less than 112 bits, or else that uses the 3DES encryption suite. Note that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network.	Reconfigure the affected application if possible to avoid use of medium strength ciphers.
	SSH Weak MAC Algorithms Enabled	The remote SSH server is configured to allow either MD5 or 96-bit MAC algorithms, both of which are considered weak. Note that this plugin only checks for the options of the SSH server, and it does not check for vulnerable software versions.	Contact the vendor or consult product documentation to disable MD5 and 96-bit MAC algorithms.
CVE-2008-5161	SSH Server CBC Mode Ciphers Enabled	The SSH server is configured to support Cipher Block Chaining (CBC) encryption.  This may allow an attacker to recover the plaintext message from the ciphertext. Note that this plugin only checks for the options of the SSH server and does not check for vulnerable software versions.	Contact the vendor or consult product documentation to disable CBC mode cipher encryption, and enable CTR or GCM cipher mode encryption.
	SSH Weak Algorithms Supported	Nessus has detected that the remote SSH server is configured to use the Arcfour stream cipher or no cipher at all. RFC 4253 advises against using Arcfour due to an issue with weak keys.	Contact the vendor or consult product documentation to remove the weak ciphers.
CVE-2016-6329	SSL 64-bit Block Size Cipher Suites Supported (SWEET32)	The remote host supports the use of a block cipher with 64-bit blocks in one or more cipher suites. It is, therefore, affected by a vulnerability, known as SWEET32, due to the use of weak 64-bit block ciphers. A man-in-the-middle attacker who has sufficient resources can exploit this vulnerability, via a 'birthday' attack, to detect a collision that leaks the XOR between the fixed secret and a known plaintext, allowing the disclosure of the secret text, such as secure HTTPS cookies, and possibly resulting in the hijacking of an authenticated session. Proof-of-concepts have shown that attackers can recover authentication cookies from an HTTPS session in as little as 30 hours. Note that the ability to send a large number of requests over the same TLS connection between the client and server is an important requirement for carrying out this attack. If the number of requests allowed for a single connection were limited, this would mitigate the vulnerability. However, Nessus has not checked for such a mitigation.	Reconfigure the affected application, if possible, to avoid use of all 64-bit block ciphers. Alternatively, place limitations on the number of requests that are allowed to be processed over the same TLS connection to mitigate this vulnerability.

[jdelio · Accepted solution]

@almay, we recommend that you contact support and open up a case with them so they can address each one of these security concerns.

[Ambidexter6]

I'm running 8.1.13. I know your issue is a bit old, but here's my input:

For the SSL issues:

• Generated a self-signed CA certificate,
• Then generated a new device certificate from the CA certificate,which is installed on the firewall.
• I've set TLS 1.2 on management (not HA) interface, pointing to an SSL profile which requires TLS 1.2, assigning the certificate to the new certificate above.
• Doing the above removes any "self-signed" vulnerability, but the "untrusted" vulnerability will remain, as the CA is untrusted.

To fix SSH issues, add the following via CLI

configure

set deviceconfig system ssh ciphers mgmt aes256-gcm
set deviceconfig system ssh ciphers mgmt aes256-ctr
set deviceconfig system ssh regenerate-hostkeys mgmt key-type ECDSA key-length 256
set deviceconfig system ssh session-rekey mgmt interval 3600
set deviceconfig system ssh default-hostkey mgmt key-type ECDSA 256
set deviceconfig system ssh mac mgmt hmac-sha2-256
set deviceconfig system ssh mac mgmt hmac-sha2-512

commit
exit

set ssh service-restart mgmt

(note. The above command causes 80-90% of my PA220s to reboot. There's a ticket in for this, but I'm not getting much traction. But after reboot, SSH, and Panorama work fine)

On 8.1.13 there's no CLI command to change the MAC for SSH. So this vulnerability will remain until we can upgrade to 9.0 or 9.1.

I am unhappy that there's no way to GUI or script or schedule some push from Panorama to the individual firewalls. I've got 60 of them, and doing these 10 or so per day is a pain. And the reboots are a REAL pain!

Regards,

Ambi