FOG SFTP HTTPS

JulienF

ok thank you for forwarding my question.
i will download 1.3.5 version

george1421

In theory its possible to use sftp for replication. You also have to be aware that during image capture the FTP server on the FOG server is used to move the uploaded images from /images/dev/<mac_address> to /images/<image_name>.

So just to be clear, the ftp server is used on the FOG server for image upload process. And the FTP server on the storage node is used for image replication.

You know what has to be configured vsftpd, so that is half of the task.

Both the FOG server and the FOS Engine (the customized linux that runs on the target computer) runs a special ftp client called lftp. From my research lftp does support sftp as long as that function is compiled in. I checked with my Raspberry-Pi FOG server at home and sftp is not compiled in based on Raspian distribution. I checked on my Linux Mint laptop and lftp does not have sftp built in either. So I’m going to suspect that if you want sftp support you will have to recompile lftp you self.

The command I used to check the lftp for ssl support is:

 ldd /usr/bin/lftp | grep ssl

ref: http://how-to.wikia.com/wiki/How_to_use_lftp_as_a_sftp_client

Now its possible for the FOS engine to supply lftp that is compiled with ssl support. The bigger issue will be for FOG servers that use the distribution’s lftp command (for replication).

I’m saying that it’s possible, with a little extra work to get a solution for SFTP. You will need some FOG developer support to change the FOG programming to use the sftp protocol over the ftp protocol. But its possible.

You will have an issue with tftp. We can use a secure tftp server on the FOG side. The issue will be with the pxe booting clients, they do NOT support stftp for pxe booting. From a FOG protocol standpoint tftp is only used to move the iPXE kernel from the FOG server to the pxe booting client. Once iPXE is running on the target computer, then the FOS engine is downloaded (bzImage and init.xz) from the FOG server over the http protocol. No confidential data is transmitted over tftp, only the iPXE kernel (undionly.kpxe or ipxe.efi).

Now on an other issue, NFS is also used to upload images from the FOS Engine to the FOG server during image capture. Some people may consider NFS as an insecure protocol.

Finally, when considering what is secure vs insecure, you have to consider the payload that is involved. You are not dealing with PII or Credit Card information with image deployment. From a security standpoint does image movements require encryption? I think you mentioned that you may use FOG to backup user computers, in that case there is the potential for PII or other regulated data to be present in the image stream, then ssl may be required.

Lastly, your english is better than mine, so what you posted is fine and clear.

JulienF

@george1421

Hi George! thanks for all these details, if i understood how it’s work, lftp is only used on the client side ?
so if i recompile lftp (thank for your ‘how-to’ link) this could resolve the issue of the image moving from /images/dev/@mac to /images/**** during the capture process.

and about the storage node, i need some modification in the fog’s files … specially the file called fogftp.class.php i presume.

ok so could you please give me a contact to ask if theses modifications are possible for the dev team ?
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

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.

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.

thank you and
have a good day !

Tom Elliott

@JulienF I’ll try taking a look at converting the “mode” from FTP non-secure to SFTP only.

For NFS, the best mechanism I can suggest is to limit “who” or “what” networks are allowed to access. This is not a hard thing to add, and I may think of a way to add something like this to automate installations in the future, though if you know the information ahead of time and make the necessary edits to your nfs exports file, you can make it so FOG doesn’t overwrite this file on subsequent updates.

I will see what I can do in regards to FTP to SFTP. As noted, TFTP will not be changed at all. This isn’t because of anything you did or didn’t do, but I’m not aware of a “secure” tftp protocol. That said, it’s only used (now) when getting the undionly.kpxe (or whatever bootfile you’re using) and possible the “default.ipxe” file. After that point it’s using http protocols.

Wayne Workman

@Tom-Elliott I think NFS can be password protected. Perhaps the installer could have an option to set that password in the inits and start building them for you at the very end of the installation… that’d be cool.

Tom Elliott

@Wayne-Workman No it can’t. Not easily and not something I’m going to try to work around.

JulienF

@Tom-Elliott

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.

george1421

@JulienF said in FOG SFTP HTTPS:

@george1421

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.

george1421

@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).

JulienF

@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

george1421

@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.

Junkhacker

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).

george1421

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.

JulienF

@ 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…

Tom Elliott

@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).

FOG SFTP HTTPS

222

11.7k

17.2k

154.7k