Contact person: PXE/iPXE Boot Development for cbt exam server only experienced are allowed

Phone:Show

Email:Show

Location: Agra, India

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"Goal: deliver a PXE/iPXE boot workflow that boots Windows and Linux machines (BIOS + UEFI) into a RAM-only, locked Chromium kiosk that points to [login to view URL] No local persistence, devtools disabled, copy/paste blocked, all traffic TLS1.3 only, MFA (WebAuthn/OTP) supported, and the image is updatable without full rebuild.

High-level approach:

Use iPXE (chainloading when needed) to load a minimal Linux image (Tiny Core / Buildroot / Alpine) into RAM.

Image runs a hardened Chromium (or Chromium-based kiosk) configured by enterprise policies and a local lockdown agent.

OS runs entirely in RAM (tmpfs/overlayfs); the only persistent artifacts optionally are signed browser and cert files fetched from a secure management server (pull on boot).

Network policies and firewall rules enforce HTTPS-only and block non-TLS.

A secure update path (update agent) pulls browser binary, certificate bundles, and policies from an authenticated update server so you can update browser or certs without rebuilding the image.

Architecture & components

Boot infrastructure

DHCP server with PXE options (next-server, filename).

TFTP/HTTP server hosting iPXE binaries, PXE menu, and kernel/initrd.

iPXE script(s) for BIOS and UEFI: present menu, then kernel + initrd or chainload PXE.

Optional: fallbacks for legacy NICs (e.g., syslinux pxelinux.0).

RAM-only kiosk image

Minimal Linux (Tiny Core or Alpine) as initrd + squashfs or initramfs.

Busybox/systemd-ish init to mount overlayfs, start network, set firewall, and launch kiosk.

Browser: Chromium (debian/chromium build) or a hardened build of Chromium with enterprise policy support.

Lockdown agent

Small shell/python agent that:

Applies iptables/ufw rules.

Mounts overlayfs on root to prevent persistence.

Disables local storage APIs via browser policies.

Ensures keyboard/mouse restrictions (no ctrl+shift+i etc).

Handles MFA UX bridging (WebAuthn/OTP).

Performs automatic updates for browser, certs, and policy files from a management server over mutually authenticated HTTPS.

Management server

HTTPS server (TLS1.3, strong ciphers) that serves:

Browser package (signed).

Certificate bundles (CA bundle & site cert if you use non-public CA).

JSON policy file for browser.

iPXE menu and update manifest (signed).

Optional: Authentication (client cert mutual TLS) for update server.

Network & firewall

iptables/nftables rules in the image to block non-HTTPS traffic and allow only TCP/443 and needed management TCP/22 (or a management port) from management subnets.

For Windows clients that chainload iPXE, ensure DHCP and TFTP are reachable.

Important caveats (read first)

UEFI Secure Boot & iPXE: Many UEFI firmwares will not run unsigned iPXE binaries. You will likely need to use the vendor-provided UEFI network boot or build a signed iPXE (requires signing with a key trusted by the firmware) OR use a very small signed boot shim or PXE menu that chainloads an HTTP kernel. A common production approach: ship a tiny signed iPXE. This is a firmware-level constraint — cannot be reliably bypassed server-side.

WebAuthn / FIDO2: Works if the browser in the PXE image supports WebAuthn and if the client’s authenticator (platform or external USB) is accessible to the OS. For USB security keys, the Linux kernel in the RAM image must provide USB support and not block HID devices. On some Windows laptops, platform authenticators are only available in Windows and not exposed to a Linux ramdisk. OTP (TOTP) works universally because it’s server-driven.

Windows kernel/firmware locks: You cannot force Windows machines to boot PXE if users have disabled network boot or require BIOS password. Practical deployments use either provisioning instructions for exam sites or provide a bootable USB fallback." (client-provided description)