Security Considerations

From FAIWiki
Jump to navigation Jump to search

Threat assessment

FAI installations 'from scratch' can not be secured due to technical reasos. Why?

Server trusts client

There's no way for the server to identify a client except by the client's MAC-adress or BIOS-provided strings. It's easy to fool the fai-server into providing client specific configuration.

Client trusts server

Since a baremetal client has no certificates, keys, etc. available, it has to trust:

  • the DHCP server to provide the correct ip
  • the TFTP server to provide the correct kernel image / initrd / nfs-server
  • the nfs-server to provide the correct root filesystem
  • the fai-server to provide the correct config space

or in case of a CD/DVD based installation .

  • noone tampering with the installation media in any way

Relevant questions

  • Do I trust my network?
  • Do I trust other machines present in my network?
  • Who can gain physical access to my network or servers?
  • Are users present? Are they trustworthy?
  • How valueable is a machine's current state? (What would happen if it is re-installed 'from scratch'? ... with a different configuration?)
  • How confidential is a machine's configuration?

And since the risk of internal attacks can not be underestimated:

  • In which ways is it possible to sabotage my environment?

In the end it boils down to assessing what are 'interesting target' in your environment and implementing suitabled attack countermeasures. If it's a proof of concept or computing cluster environment then it may be sufficient to tighten down the dhcp server a bit. If it's a datacentre then opting for an out-of-band installation network with a supervised installation schedule may be just one piece. This would at least guarantee nobody is able to sniff/subvert unencrypted traffic.

Hardening

Network based installation

DHCP

Unencrypted protocol and easily subverted by a rogue dhcp server. The 'safest' approach would be to disable network booting on each fai client and only enable if an installation is scheduled. Depending on how this can be achieved this may defeat the purpose of fai to enable an automated installation without any user interaction.

Hardening options:

  • It is possible to limit the effect of a rogue dhcp server by splitting the network on layer 2 and either

set up 'local' dhcp servers or configure dhcp forwarders.

  • Don't use dhcp.

TFTP

Unencrypted protocol. No authentication possible, everyone can download all kernels / initrd and the boot configuration for each client. This make tftp unsuitable to provide critical information.

Hardening options:

  • Don't use tftp.

Filesystem root image

Usually provided via NFSv3 and therefor unencrypted.

Hardening options:

  • Use NFSv4 instead of v3
  • Tunnel NFSv3 through SSH

Please note: Encryption may add no security if the relevant tokens are obtained via unauthenticated/unencrypted channels. (e.g. initrd via tftp) Please scrutinize your setup carefully and decide accordingly.

Media based installation

Someone may tamper with medium to provide a subverted configuration or software packages

Media integrity

  • Provide a checksum one can use to verify a medium's integrity
  • Use local ressources or implement measures to verify external resources' validity (e.g. package signing key)

Configuration space

Gaining access to the configuration space is usually quite easy if it is somehow possible to participate in a physical network used to install fai clients. If one can camouflage as a legitimate fai installation client (e.g. by faking a valid fai client's MAC adress) then gaining access to the config space is probably trivial.

Access to a legitimate FAI config space could be used to start a man-in-the-middle attack and modify a client's installation process. (Change configuratio, add additional software, reinstall or wipe existing clients).

Hardening options:

  • Provide config space from a trusted source or via a verifyable access scheme (like ssh+svn:// or https:// instead of nfs://)
  • Provide FAI server functionality only if an installation is actually performed.

Client->Server callback

Allowing fai clients to modify the fai server's state should be reviewed very carefully. Since the fai server essentially provides clients with an ID a potential attacker can camouflage easily as a valid client.

disable auto-install

The way it is currently implemented there are essentially three ways a client could use to automatically disable automatically starting a new fai installation after reboot..

  • ssh + fai-chboot
  • edit tftp boot files directly
  • faimond -i

SSH + fai-chboot seems to be the safest since establishing the ssh connection requires some kind of authentication and the traffic is encrypted, but if the fai-server provides the necessary tokens via unencrypted protocols it's actually not much different then a telnet session.

TODO

- discuss content

- gather more input / facts / tips

- take a closer look at faimond and possible exploits

Retrieved from "https://wiki.fai-project.org/index.php?title=Security_Considerations&oldid=3370"