I apologize with all sincerence if you had the impression I'm trying to attack you. I didn't intend to at all.
> I don't see big flashing 'thou are forbidden to harden your install as > you see fit' in the manpage either. No. There isn't. I wrote this reply, because on the outside it _seems_ ssh+fai-chboot is a safe way to disable auto-installs. >> Does nobody see the fault in having >> - a NFS-share mountable by any client [on a specific network] > _any_ client? Only if you totally don't care about preparing the > exports file... Any client (or actually ip-address) that is supposed to be installed by fai. Typically that means there's a DHCP server handing out IP-adresses and a /etc/exports which allows NFS-mounts from these adresses. This may result in just needing to locate a network socket and connect a device or simply reboot the device you're given. Possible countermeasure: - deny physical access to network / machines - deny read access to fai logfiles - secure DHCP by implementing a MAC-Whitelist. - secure network sockets by implementing MAC-based ACLs - install clients in a 'safe' environment and reconfigure network later on (possibly by using vlans) >> - a SSH-Key without a passphrase stored in that NFS-share >> - a login account allowing (at least) the manipulation of other hosts >> boot-settings > Limiting access through ssh on the business address of your fai server > to sume short list of machines is pretty much straightforward. The question is not whether it's easy or not. The question is if you thought about it beforehand. Especially if you're a beginner and do not fully understand all implications (that's why you're a beginner) some hints on what to remember would be nice. Using ssh gives a sense of false security in this case and that's what I'm worried about. Additionally this access limitation on the fai-server does nothing if you gain access to a legitimate fai-client. After all it's supposed to access the server and log in. >> NFS traffic is not even encrypted. This means the private key is >> transmitted in plaintext over the wire. From a security point of view >> there's not much difference if one simply uses telnet instead of ssh. > True 'as is' in fai - not true in general. NFS traffic can be encrypted. > Feel free to add krb5p to fai features. If I had to implement from scratch then it would be something along the line of handing out a token (randomized, unique, non-reusable) to the client before starting the installation and the client pushing back that token after the installation has finished. The token must be unique for every installation. Even if it's the same client. Think of a one time password. - install starts - client retrieves randomized, unique token (e.g. wget https://faiserver/token?action=get ) - client installs - client sends token + status update to server (e.g. wget https://faiserver/token?action=set&token=<abc>&state=success ) The server decides what to do. Ignore the token if it's invalid? Write a mail? Send a sms? Disable network boot? Alarm the operator if the same token is used twice? That way it wouldn't be necessary to encrypt the nfs traffic, allow passwordless login and harden the login account against tampering. >> This is probably not relevant if using fai to install a compute-cluster >> in a trusted network environment. If the environment is not trusted >> (training classroom? datacenter?) then please implement appropriate >> measures. > 'Please implement'? > Sorry, I'm not the developer of FAI. Nor is Ivan AFAIK. > And I think you're not the funding agency behind Thomas Lange either. It wasn't meant in the sense of "Please write code". It was meant in the sense of "Think about your own environment and implement appropriate measures." If it's just a computing cluster in a trusted network environment, then the appropriate measure would be to do nothing at all. At my previous employer we had a vlan dedicated to fai. We reconfigured the clients network port to the client's 'production' vlan after the installation has completed.
