Network boot is commonly used for everything from booting thin clients to using IT automation for bare-metal provisioning. Unfortunately, most network boot infrastructure is based on outdated standards encryption or authentication. This presents an issue when implementing a Zero Trust architecture, where security principles need to be implemented within the network perimeter. Fortunately, modern alternatives exist using open source solutions.
Most network boot deployments are based on Pre-Boot Execution Environment (PXE) defined by Wired for Management (WfM) in the 1990s. PXE allows a client to boot on a local network. The architecture is based on the 16-bit Basic Input/Output System (BIOS) and requires a network controller to provide a low-level driver based on the Universal Network Device Interface (UNDI) format. PXE works around limitations of 16-bit BIOS architecture by relying on simple network protocols: Trivial File Transfer Protocol (TFTP) and User Datagram Protocol (UDP) broadcast.
As network technology has improved, the limitations of PXE Boot are more apparent. PXE has no mechanism for encryption or authentication, is susceptible to man-in-the-middle attacks, does not scale outside of local networks, and has reliability issues associated with TFTP time-outs and UDP packet loss.
The UEFI Specification introduced HTTP(S) Boot in in version 2.5. HTTP Boot combines the Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Hypertext Transfer Protocol (HTTP) to provide system deployment and configuration capabilities over the network. Compared to PXE Boot, HTTP Boot can handle much larger files than TFTP, and scale to much larger distances. PXE depends on UDP broadcast You can easily download multi-megabyte files, such as a Linux kernel and a root file system, from servers that are not on your local area network.
One of the key issues with PXE is a lack of security. The TFTP & UDP transactions associated with PXE may be the last unencrypted traffic on your network and are trivial to intercept. This boot process goes against the “zero trust” concept applied to today’s networks.
“Zero Trust is a security concept centered on the belief that organizations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.” – CSO Online, Jan 2018
The UEFI network stack model added IPv6 and TCP, along with support for signed bootloaders with UEFI Secure Boot, but those improvements do not address the fundamental limitations of PXE architecture. Migrating network boot to HTTP(S) addresses these limitations and can be deployed on today’s platforms using open source solutions. TianoCore, the open source UEFI implementation, features a network stack with HTTP(S) Boot support that is integrated in most commercial platform firmware. Linux distributions like SUSE SLES 15 and openSUSE 42.3 can install from a host server via HTTP(S). These implementations leverage UNDI drivers already provided by network device manufacturers.
Stephano Cetola, Open Source Program Manager at Intel, will be discussing this issue at Open Source Summit North America 2019. Check out his presentation, “Network Boot in a Zero-Trust Environment with UEFI”, on Friday, August 23 at 11:30am.
Los compiladores Intel pueden o no optimizar al mismo nivel para los microprocesadores que no son Intel en optimizaciones que no son exclusivas de los microprocesadores Intel. Estas optimizaciones incluyen los conjuntos de instrucciones SSE2, SSE3 y SSSE3, y otras optimizaciones. Intel no garantiza la disponibilidad, funcionalidad o eficacia de ninguna optimización en microprocesadores que no sean fabricados por Intel. Las optimizaciones dependientes del microprocesador en este producto fueron diseñadas para usarse con microprocesadores Intel. Ciertas optimizaciones no específicas de la microarquitectura Intel se reservan para los microprocesadores Intel. Consulte las guías de referencia y para el usuario para obtener más información acerca de los conjuntos de instrucciones específicos cubiertos por este aviso.
Revisión del aviso n.° 20110804