FOG 1.5.6 Officially Released
-
@Sebastian-Roth @george1421 @Wayne-Workman
While I agree that the self signed warnings are annoying; from a security standpoint it is still better and common for many self hosted services. Web communication should be secure even if it is less convenient. The fact FOG has so much power over clients (forcing re-installs, running snapins) means that the login to the web ui HAS to be encrypted. Most management services default to self signed and provide the option to replace with a thirdparty / external cert. Adding a UI element to streamline this (eg upload third party cert and restart fog from the UI) would make it more user friendly. This is the default with JAMF (tomcat) and Solarwinds.
I do agree that looking at requiring a mysql password and configuring the firewall should be addressed too.
-
It’s worth noting that FOG is open source and runs on Linux and Apache. There’s a thousand articles on the internet about applying SSL to Apache. Anyone can secure their FOG installation with a self signed cert, or an organization-trusted cert. One could even say that securing things with SSL is the admin’s job.
-
I agree that applying a cert in Apache is simple but I also believe the best experience is to meet a minimum level of security out of the box so to speak. Honestly I would say that moving the require https out of the installer flags and making it one of the dialogues (like the questions about network config) would be good enough. At least then new users (even ones following random out of date guides online most of which don’t reference the installer script flags) would be able to choose.
-
@astrugatch said in FOG 1.5.6 Officially Released:
Adding a UI element to streamline this (eg upload third party cert and restart fog from the UI) would make it more user friendly. This is the default with JAMF (tomcat) and Solarwinds.
As discussed here it’s not as easy as it sounds: https://forums.fogproject.org/topic/12926/fog-behind-reverse-proxy
But I am with you that we should encourage more people to make it more secure and one important step would be to ask within the installer. Just not sure yet if we make the default choice yes or no.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
To be clear I’m mostly speaking about the web UI right now. But the client would be important too. The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.
-
@Sebastian-Roth Really when you think about it, its not an either or situation. Why not setup both http and https in apache. Neither is dependent on the other.
So go ahead and by default create the apache self signed certificate and spin up both http and https in apache (to different config files so the FOG admin can stop http if wanted). Make the self signed public root certificate available so the IT admin can download it and install it in his/her computer’s trusted certificate store then no more warnings in the web browser for certificate issues. (we did something similar with our vSphere environment where vCenter creates its own self signed certificates)
The issue will be with making ipxe https compliant. Those binaries could be problematic on the target FOG system. IT can be done, but then FOG will need to load the compiler and development libraries to compile iPXE. It can be done, its just one more failure domain.
(thinking out loud here) I wonder if FOG can create a valid certificate chain, then create the local certificates via a subordinate CA. So if the FOG Project created a root level trusted certificate then all FOG servers would then create their self signed certificate (as a subordinate CA) from the FOG Project trusted root certificate. The iPXE binaries could be compiled against the FOG Project trusted root certificate by the FOG Project devs. Would those work in this new SSL environment since everything would have a common trusted root? (just guessing). Would this be any different situation from what Verisign or other trusted root providers do?
-
@george1421 said in FOG 1.5.6 Officially Released:
Why not setup both http and https in apache.
I’d say that’s a good idea.
-
@astrugatch Sorry for my late reply. Just too many other things so I set this aside for a bit…
To be clear I’m mostly speaking about the web UI right now.
Ok fine. I will work on adding that to the installer in a way that more people might use it.
But the client would be important too.
What exactly to you mean? We do state of the art encryption between fog-client and FOG server ever since the current fog-client was released (compared to the old legacy client). Anything more we need here?
The way JAMF handles the migration is that it continues to use its internal CA and distributes the new cert to the machines on check in. It keeps track of those that have received the cert and compares that to its list of enrolled machines. When all machines have received the cert there is a UI element that goes from red to green letting you know that the server can now be switched to communicate via the external CA.
Yeah this is highly advanced certificate handling that I would love to add to FOG but probably won’t find the time to do so any time soon. We are on the very edge with way too little work force working on FOG.
I’d prioritize the mentioned database password security now. Follow up topic here: https://forums.fogproject.org/topic/13267/database-security
-
If the FOG client uses HTTP to communicate, is there any reason that we have to use the generated self-signed certificate for HTTPS?
Why not run both but allow the admin to change the cert for just HTTPS? No need to change the way the client works but allows the admin to use a signed certificate if they want to avoid the browser warnings.
I kind of do this now except I use the FOG generated certificate. I do not really mind the browser warning (as long as they do not start outright blocking it).
I have not tested this using my signed certificate but I can test it next Monday if there is interest.
-
@jburleson if the cert you’re using is signed by the fog server, and the machines you are using to access the server have the fog client on them, then you shouldn’t get the warnings either as the FOG CA signed the certificate and it’s relevant chain is also trusted by the machine.
-
@Tom-Elliott For Windows 10, I think this is only true if you use Microsoft Edge. If you use a different browser (Firefox, Chrome, etc.), then you will get the browser warning until you add an exception for the cert in the browser. At least that has been my experience so far on all the Windows 10 machines that I have deployed.
-
@jburleson for Firefox yes but chrome uses the windows cert store
-
@jburleson Yes both firefox and chrome uses the windows cert store as Tom posted. I know because we had to do this with our vCenter servers. You need to take the public root certificate of the self signed certificate and import it into the machine’s trusted root certificate store. Once you do that then there is no warnings in any of the three browsers.
While these instructions are specific to vCenter the process would be the same for any self signed root certificate. https://tinkertry.com/how-to-get-rid-of-vsphere-browser-certificate-warnings-in-windows
-
An issue was found in 1.5.6 that calls for an early next release to fix that. Find the details here if you run into problems with FTP connections on kernel updates or storage nodes in 1.5.6: https://github.com/FOGProject/fogproject/issues/311
