Fog Server vulnerable
I hope y’all stay safe and well.
My institution recently did a pen test a found a few vulnerabilities on the FOG server:
Vulnerable version of product HTTPD found – Apache HTTPD 2.4.6
Vulnerable version of component OpenSSL found – OpenSSL 1.0.2k-fips
Configuration item ftp.plaintext.authentication set to ‘true’
Insecure MAC algorithms in use: hmac-sha1,hmac-md5
Negotiated with the following insecure cipher suites:
* TLS 1.0 ciphers
If I manually upgrade APACHE and OpenSSL to the latest versions 2.4.52 and 3.0 respectively, would this break FOG in any way? I’m using FOG Version 1.5.8 on Enterprise Linux Server release 7.9 (Maipo).
Does openSSL version 3.0 resolve Insecure MAC algorithms and insecure cipher issues? How do I go about fixing ftp plaintext authentication issue?
@tata The short answer is you can update your OS with patches and they will not impact FOG. This is something you should do.
So apache, openssl can be updated no problem.
The insecure MAC alg. Is probably related to ssh allowing insecure authentication hashs. You can just update the sshd server configurations to fix this. FOG doesn’t use SSH so there is no impact there.
TLS 1.0 cipher might come into play if you are using ssl (https) for your web site. While I don’t know for sure, you might run into a conflict with the FOG clients if they are configured to use TLS 1.0. The fog clients connect to the FOG server on port 80. So I would make the change to only allow 1.2 and see if the fog clients have an issue. If you have storage nodes, then also watch the master node to make sure its getting performance metrics from the storage node.
The troubling one is the ftp plain text auth. There is no getting around this one right now. I’m suspecting they want you to use certificates instead of plain text, or possibly something like sftp or ftps. Right now FOG is not configured to use the ssl or tls versions of ftp.
These trouble points you mention makes me think you had a compliance audit. I would think the FOG server should be excluded from the audit since it doesn’t contain PII or credit card data.
Thank you very much @george1421. I will update apache and openssl to see how it goes.
We are not using fog clients or https so I’m not so worry about TLS 1.0. I couldn’t get https to work when we configured FOG in the past so I gave up on it. We only have one storage node and it’s on the same server.
You are right. We had a compliance audit. I will ask the security team to see if they can make an exemption on the ftp part.
Thanks again for your help.
@george1421 I updated httpd to httpd2.4 version 2.4.52. Webservice is running but FOG webservice is not. I’m getting URL not found. I know there is an easy fix but I couldn’t find it on my note. I forgot to take a snap shot and don’t want to mess around to cause more damage =). Could you please point me some hint how to remedy this issue?
Please scratch out my previous question.
systemctl enable httpd.service resolved it.
@george1421 I updated FOG to 1.5.9 while working on these issues and was able to enable HTTPS with a custom cert. The site was loading fine/we were able to clone images from FOG server.
The security team also wanted me to update PHP 7.2.34 and mysql to the latest version.
I updated PHP to 8.1.3 and now the website is not loading. I’m getting HTTP ERROR 500.
What are the right steps to update php and its dependencies and MYSQL?
Sorry for asking too may questions.
@tata FOG 1.5.9 does not support php version 8. You need to upgrade to the dev branch for that. Personally I would have taken php and php-fpm to version 7.4 and not jumped to php8. As for mysql there should be no problem upgrading to latest database. But I do have to caveat I have not tried to move beyond the versions shipped with the fog server host OS distro version.
@george1421 @Sebastian-Roth Thank you all for your help. I downgraded to php7 but couldn’t get around the HTTP error 500. We didn’t take a snapshot of the VM before messing around with it. It took a while for the admin to restore our FOG server from the backup. I’m staying at PHP 7.4.28 and mysql 5.7.33 for now.
Thank you all for your help.
You are welcome. You might want to ask in the forums before jumping right into it next time.
I downgraded to php7 but couldn’t get around the HTTP error 500.
The apache and PHP-FPM logs are your friends in finding out what’s wrong. See my signature on where to find those.
We didn’t take a snapshot of the VM before messing around with it.
Next time you will, I am sure.
It took a while for the admin to restore our FOG server from the backup. I’m staying at PHP 7.4.28 and mysql 5.7.33 for now.
So things are back to normal for now, right?
@sebastian-roth Yes, sir! Lesson learned…for now.
@TaTa I guess code is probably the best documentation you can get for this particular question:
@tata Beyond looking at the code, what do they expect you to produce? Yes plain text FTP is used. Its only used in the context of the application. At no time under the normal operation of FOG does a user or fog admin use FTP to access the server. Its only used by back end FOG services for image movements within FOG. I’m not sure what else they might want.
Thank you all for your help. I was able get an exemption from the security team for ftp plaintext. I’m down to the last issue about the nfs mount points and folder permissions. They don’t like the fact that these mount points are open to everyone. What is the proper way to secure them?
I currently have:
What is the proper permission for /images folder (and sub folders)? It is now set to drwxrwxrwx. fogproject root 4096.
@TaTa The default NFS in FOG is still version 3 which has no concept of user authentication/authorization. Sure you can try to lock things down a bit by setting access rights on the FOG server filesystem.
But if you want to go beyond that you will need to look into NFSv4 which is not implemented yet: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3