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

[Michał Dwużnik]

Hi Thomas,

> I apologize with all sincerence if you had the impression I'm trying to
> attack you. I didn't intend to at all.
>

Apologies if I overreacted, too.

I find it very useful to talk about vulnerabilities, sorry that
particular phrasing of 'Does nobody see the fault in...' made me
read 'Please implement' as a really bad way of writing a feature
request to the dev...

>> 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.
>
Bookkeeping matters ;)
Typical practice is a dhcpserver which does not respond to unknown MACs
with anything allowing the install.
And exports set up e.g. to respond to only machines from ethers (NIS+arpwatch+
'stop install server on the first packet from unknown MAC') and/or
only within some timeslot.

For particular machine types I can imagine basing on MAC as first step,
and checking for the default config of managament module for example
in the install process
(matching service tags). Normally one in charge of installing the OS
has access to
'what's inside this machine' info.

As Thomas stated -> the main pitfall is PXE itself, with the silent
assumption of
an immutable MAC.

> This may result in just needing to locate a network socket and connect a
> device or simply reboot the device you're given.
>
'connect a device + fake a MAC of a one known to server' is much worse
as it bypasses some of the countermeasures below (which also
'make it sound safer to do...')

I'll describe where I'm going to use FAI:
> 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
not as good as it seems unfortunately. Faking a MAC again kicks in.

>  - install clients in a 'safe' environment and reconfigure network later
> on (possibly by using vlans)
>
Vlans + 'timeslots'. Install server can easily be active only at times
of foreseen installation ->
if that's a test workbench -> it's usually safe an isolated,
if it's 'big bad world' with accesible sockets, open network et al. ->
I can hardly imagine a situation
where remote unattended installs would be applicable without some
dedicated 'management time'
with no people around.


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

For the sake of beginners -> I would bet they do their first tries in
quite a well defined and separated network
(like virtual guests on physical home, or 'home' situation behind a NAT).
If you can get a hand on a network where those issues are really
dangerous you shouldn't be a beginner in the first place.

> 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.
>
Can be partially done via recreating the keys after each install ;>

> - 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?
>

Nice idea from first glance. No time to dream of it now, sorry.

> That way it wouldn't be necessary to encrypt the nfs traffic, allow
> passwordless login and harden the login account against tampering.
>

Regards
Michał