How to prevent new installations when I have already installed my client through LAN boot?

[Thomas Neumann]

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.