FOG SFTP HTTPS
-
@Wayne-Workman No it can’t. Not easily and not something I’m going to try to work around.
-
ok tanks a lot !
for NFS i’m agree i can securise access directly i can find a trick for this, network or permissions (is it NFSv4 which is used?).
About TFTP i asked because i read that iPXE is capable to works with HTTP/HTTPS ISCSI …etc but maybe i’m wrong. so in case of the exchange by tftp, if it is only sending undionly.kpxe or other .pxe files it’s not a real problem
anyway thanks for taking a look on sftp, it’s really very nice !!
and thank you for your advise.
-
@JulienF said in FOG SFTP HTTPS:
Hi George! thanks for all these details, if i understood how it’s work, lftp is only used on the client side ?
The lftp program is used in 2 places.
- In the FOS engine (this one will be easy to update, since the fog developers manage this program and could recompile with ssl support). (Understand I’m not speaking for the developers on how easy something is to do, only that its possible). In this case you will need to update the vsftp program on your master FOG server to support sftp.
- the lftp program is used on the Master FOG server to move files from the master FOG server to the remote storage nodes. In this setup, you would need to recompile the lftp program on your master fog server, and then configure the vsftp on the remote storage nodes to support sftp.
- You will need to guidance of the developers to change the lftp call that starts the program with the ftp uri to sftp uri.
ok so could you please give me a contact to ask if theses modifications are possible for the dev team ?
The senior developer has already replied to this thread.
I am not aware of the complexity of the task but if it does not take them too much time and too much effort I will be really glad that they can do it
$$$ anything is possible for the right price $$$. Don’t forget to donate to the FOG Project
about the question of TFTP protocol, i’m agree with you, only kernels files pass trough this protocol and they are not critical…if i can explain this at my company it must be fine.
This is correct. What you need to understand is the risk based approach to security. It should be easy to understand.
about NFS security, i will see how my company restrict this usage… but if i ask to your team to change all used protocol in FOG it’s not the solution… you make an excellent job and first if only FTP can be changed to SFTP it will be great.
As for NFS security this will be a very tough one. NFS v1 is not secure at all. The best we can do with FOG 1.x is restrict access to the NFS shares on the master node and storage node by IP address. If you are not in the defined range, then no access. If you are in the defined range, then you have access. Its not the best, but what we have to work with.
I don’t really want to talk about FOG 2.0 (because its about 2 years away), but that platform will have security built in from the beginning and not try to add it on after the software has already been built.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@JulienF said in FOG SFTP HTTPS:
for NFS i’m agree i can securise access directly i can find a trick for this, network or permissions (is it NFSv4 which is used?).
I mentioned this in another post, NFSv1 only. Remember we have to rely on what the distribution uses for NFS, and we can’t mandate that NFSv4 be used.
About TFTP i asked because i read that iPXE is capable to works with HTTP/HTTPS ISCSI …etc but maybe i’m wrong. so in case of the exchange by tftp, if it is only sending undionly.kpxe or other .pxe files it’s not a real problem
This issue is not about FOG, but the PXE ROM inside the target computer. They mainly support tftp to transfer the boot image to the target computer. FOG could require secure tftp, but then we run the chance that some clients may not be able to boot via pxe. Once the iPXE kernel is installed and running then we can enforce better security. (again speaking as a moderator and not a developer).
-
@george1421
thanks George for all these details ! i understood for tftp and NFSv1.TFPT : no critical data pass though
NFS: i understood what you mean. Do you know if it’s possible to encrypt datas (image captured) with partclone without additional dev (i didn’t found an option like this on fog interface?) i’m aware that an option like this decrease performance of capture/deploy process. but it’s just a question (clonezilla can do it for example).
@Tom-Elliott
When you write “For NFS, the best mechanism I can suggest is to limit “who” or “what” networks are allowed to access” you mean that it is possible to add some information like a network allowed (in etc/host.allow? and /etc/host.deny ?) in my case it will be complicated cause we have only one subnet for all clients. but if it’s possible to configure a list of mac address it could be good. and i can configure it by myself … without bothering you ^^thanks to all for your responses and explainations!!
PS : @george1421 : It is a very nice project and I intend to give something to help your team and respond to your listening, your involvement and your advice
-
@JulienF I know you ask this of Tom, I answered something similar in this thread, based on an audit observation: https://forums.fogproject.org/topic/9742/need-to-close-vulnerability-exported-volume-is-publicly-mountable/11
This is the only way I know of with NFSv1 to restrict access.
-
i don’t think anyone has mentioned this so far, so i feel i should: FOG is not designed to be a backup solution. It is a systems deployment/management solution. Generally speaking, images are not expected to contain sensitive data (it’s usually just Operating System, and some programs, tweaked the way you want it).
-
I agree with Junkhacker FOG is not a backup solution, not really. If you want a good low cost backup solution look at Veeam Endpoint backup.
As for encrypting data at rest, its possible. (I know if I keep saying: “its possible”, the developers will take my key to the executive washroom and make me use the gas station down the road…)
Its possible to stream the data as it comes out of the data compression (pigz) and to stream the data through gpg to encrypt it. gpg supports both reading from standard input and writing to standard output. So it could be inserted in line. This additional step to encrypt a 40GB disk image file would really slow down image capture and deployments destroying the best part of FOG (its speed). But in theory its possible.
I would have to question the value of adding this into FOG, you have a specific use case that is not typical for most FOG Admins. So I would have to ask if its worth the developers time to spend adding encryption for one or two FOG installs over working on the program to add features for many FOG installs?? I don’t have an answer for that.
-
@ George1421 @Junkhacker
Yes i see what you mean fog is firstly designed for mass deployment …
And in this case ok, security is not a priority when only ‘simple’ images transit by network … maybe i need to review my choice. I know Veeam, but the interface management of fog is awesome and could be a good way to manage backups, pc groups and to remotely work with WOL…I have to think about it and and maybe reconsider my goal… -
@JulienF I will still work to add a potential for “securing” the aspects that can be secured.
As far as your NFS route, you only have a single subnet to worry about. You could create a secondary “subnet” for FOG imaging if you needed, or just restrict NFS to use that single Subnet (making it no longer publicly (globally) accessible).
