How to remove SSH weak algorithms and not impact ipsec tunnels.

[Metgatz]

Hello, good evening. Thank you very much in advance for your help and support as always.

Checking this link: https://live.paloaltonetworks.com/t5/general-topics/how-to-remove-ssh-weak-algorithms/td-p/285933#:~:text=Next%20Topic-,1%20ACCEPTED%20SOLUTION , -Reaper

Fair, but fair (murphy) I need to apply these settings at the SSH and SSL/TLS level in some PCI firewalls, which have a lot of IPSEC vpn tunnels, site to site (a lot I'm talking about more than 50 tunnels with a mix of suite of algorithms). Reviewing what a colleague/colleague comments, when applying the settings, he had problems with his vpn-site-to-site tunnels: This is in the Live Community Link: https://live.paloaltonetworks.com/t5/general-topics/how-to-remove-ssh-weak-algorithms/td-p/285933:

""""

... Exit from config mode by typing 'exit' > set ssh service-restart mgmt I ran these commands and it appeared to work, however shortly afterwards our VPN site to site tunnel dropped out. I connected to our PA-820 again, ran: delete deviceconfig system ssh commit set ssh service-restart mgmt. and after a few minutes the tunnel came back up. Would running those commands have disabled a cipher suite used by this tunnel?"""""

I have the same case... where an asset vulnerability management tool detected these ssh encryption issues: SSH Weak Algorithms Supported: Has detected that the remote SSH server is configured to use the Arcfour stream. RFC 4253 advises against using Arcfour due to an issue with weak keys. I assure you that in the total number of ipsec tunnels of these firewalls, a mix, there will be everything, 3DES, SHA1, MD5... a little of everything, the issue is how do I make sure that the SSH and SSL/TLS configuration, when making the adjustments, remove the weak algorithms, especially in ssh, do not impact the ipsec tunnels, as happened to the colleague, who published in the live community, who had to choose to cancel/delete the adjustments made and go back to restart the ssh service and then the ipsec tunnels are working again.

Just these firewalls that I have to intervene are critical but very critical, effectively because of the multiple ipsec tunnels.

I look forward to your comments, support and/or suggestions.

Thank you Best regards

[OtakarKlier]

Hello,

I'm sure its not the answer you would like, however I would suggest rebuilding all the tunnels to FIPS 140-2 standards. i.e. DH groups 14,19 or 20, SHA256 and AES 256 ( i know lower numbers are still FIPS, however I suggest 256 or higher if supported. Once rebuilt, then worry about removing the weaker ciphers from the devices. Failure to do so will, like you found out, cause downtime.

Regards, 

[Metgatz]

@OtakarKlier 

Hello, thank you very much for your reply.

I set up a lab, with two PA VM-100 9.1.2, I set up an IPSEC tunnel, I made sure it was up and OK. I used for this quite basic and weak encryption and authentication algorithms, sha1, md5, des, 3des and dhgroup1. The tunnel lifted OK without problems.

Subsequently to the tunnel above, I applied the disable both at ssl/tls and ssh level, the weak algorithms leaving this way the config:

SSL: show shared ssl-tls-service-profile CaTLS protocol-settings
protocol-settings {
min-version tls1-2;
max-version max;
auth-algo-sha1 no;
enc-algo-3des no;
enc-algo-rc4 no;

SSH MGT:
admin@PA-VM# show deviceconfig system ssh
ssh {
ciphers {
mgmt {
aes256-ctr;
aes256-gcm;
}
}
default-hostkey {
mgmt {
key-type {
ECDSA 256;
}
}
}
regenerate-hostkeys {
mgmt {
key-type {
ECDSA {
key-length 256;
}
}
}
}
session-rekey {
mgmt {
interval 3600;
}
}
mac {
mgmt {
hmac-sha2-256;
hmac-sha2-512;
}
}
kex {
mgmt {
ecdh-sha2-nistp521;
}
}
}
[edit]
admin@PA-VM# 

When I applied this, at no time did the tunnel go down ... at no time did the tunnel lose connectivity, and I set up the tunnel with weak algorithms. I even applied restart to the tunnel, restarted one of the computers, applied the settings to both firewalls and the tunnel is established without problems.

Here my doubt, the issue of ipsec tunnels, after applying the hardening of ssh, the problem that had the colleague / colleague is a documented bug of some version ? was a very specific situation that happened to the colleague ? was it just a parallel issue out of control that happened or that problem occurs with version 8.0.X or 8.1.x but no longer with versions 9.1.X ? Since in my lab, I had no problem and I can connect via ssh without problems, with strong encryption and also at ssl level.

I remain attentive, thank you very much, best regards.

[OtakarKlier]

Hello,

Let me back up a sec. The settings you wish to change are for the management plane only. The VPN tunnels are created on the data plane so as you found out, they should be unaffected. So I would recommend you run a supported version of code:

https://live.paloaltonetworks.com/t5/customer-resources/support-pan-os-software-release-guidance/ta-...

But I also would recommend using ciphers on your tunnels that are FIPS compliant. One Issue I recently found is that if you enable FIPS mode, your tunnels need to have compliant ciphers. Might be tricky down the road if you still use older ones, not to mention someone might be able to decrypt the traffic.

Regards,

[Metgatz]

@OtakarKlier 

Hello, thanks for the answer, it is effectively being applied at the level of management plane, therefore nothing is touched at the data plane level, which is where site-to-site vpns flow.

The great doubt that I remain and that is why my concern is based on what the colleague / colleague executed. If you see the article and the post, he also executed the ssh themes on the mgt, that is, on the management plane , and had problems with their tunnels, that's why I'm worried and let's just apply this, in a very critical firewall, for the site-to-site vpn.

Link of the detail of the colleague/colleague and his inconvenience with the tunnels, after applying, and only to ssh/mgt, according to what I comment with the commands that I execute:

https://live.paloaltonetworks.com/t5/general-topics/how-to-remove-ssh-weak-algorithms/td-p/285933#:~...

I remain attentive, cordial greetings.

[OtakarKlier]

Hello,

I would recommend updating your tunnels with FIPS ciphers and during a maintenance window that has been approved by change control.

Regards,

[Metgatz]

Hello @OtakarKlier Thank you again for your collaboration, follow up, support and help.

What I do not quite understand and do not quite convince me, as a change that is focused on the management plane, which is focused on the MGT and only encryption and authentication algorithms are specified, focused on ssh, as this ends up impacting the data-plane, with the fall or possible fall of the ipsec tunnels, if the settings are explicitly focused on what is used by ssh, should not and would not have to cancel, delete or disable the algorithms focused on the site-to-site vpn, the truth is that the logic says that there should not be problems, but I do not understand why there is this latent risk, if the site-to-site vpn vs ssh issues are totally different issues and I reiterate in my lab, using multiple combinations of algorithms for the tunnel and applying the hardening of both SSH and TLS/SSL, at any but at no time I had problems with the test tunnel I established, this tunnel used as test, MD5, 3DES, DES, SHA1 and DH1 and I had no problem whatsoever.

I remain attentive, greetings and attentive to your comments.

[OtakarKlier · Accepted solution]

Hello,

I understand your concerns. I always try to have a change management approved for all firewall changes. This way I'm covered if anything goes sideways. To your point about the VPN tunnels, anything man made is prone to potential issues (bugs, etc.). For this reason is why I stated what I did. A roll back plan is always a handy thing to have as well.

Hope that helps.

[Metgatz]

Hello @OtakarKlier 

Thank you for your reply.
Of course, as always, we have to set up the corresponding change control, controlled window and have the rollback plan ready in case of any inconvenience, well, let's hope that this is not the case and that it works as well as in the Lab.

Thanks for your time, best regards