Habr•October 23, 2026•🇷🇺Translated from Russian

Secure Boot on Arch Linux: Enabling Protection for UKI Without Replacing Factory Keys

Arch Linux, unlike many other distributions, does not enable Secure Boot by default. Installation requires it to be disabled, although users can sign the image themselves. Once enabled, the Arch Wiki offers several configuration methods, but navigating them can be confusing for newcomers.

Secure Boot can be set up using sbctl by replacing all factory UEFI keys, through shim, or by adding a key directly via the UEFI interface. This article provides a step-by-step walkthrough of the third option: adding a custom key through the UEFI menu for use with UKI (Unified Kernel Image).

The goal is not to create an unbreakable Secure Boot setup but to achieve basic protection comparable to the default configuration on Windows. The author avoided shim because it depends on Microsoft certificates and rejected sbctl enroll-keys -m because it replaces the entire PK → KEK → DB chain, which carries higher risk and blurs responsibility between operating systems.

Step 0. Backing Up Keys

Before making changes, back up the existing keys using a FAT-formatted USB drive. Enter the UEFI BIOS, locate the Secure Boot section, and select “Save all keys.” Choose the USB drive from the list of disks. After saving, copy the files to a safe location so they can be restored if needed.

Step 1. Generating the Key

Boot into Arch Linux and install sbsigntools:

sudo pacman -S sbsigntools

Create a secure directory and generate a new 4096-bit RSA key valid for ten years:

sudo install -d -m 700 /etc/secureboot

sudo openssl req -new -x509 -newkey rsa:4096 -sha256 -nodes -days 3650 -subj "/CN=My Arch Linux Secure Boot/" -keyout /etc/secureboot/db.key -out /etc/secureboot/db.pem

Convert the public key to DER format for UEFI enrollment:

sudo openssl x509 -in /etc/secureboot/db.pem -outform DER -out /etc/secureboot/db.cer

Step 2. Enrolling the Key in UEFI DB

Copy db.cer to a USB drive and reboot into UEFI. In the Secure Boot menu, add the new key to the DB section. After saving and rebooting, sbctl list-enrolled-keys confirms the custom key appears alongside existing Microsoft and ASUS certificates.

Step 3. Signing the UKI Automatically

Create a post-hook script at /etc/initcpio/post/uki-sbsign that signs the UKI whenever mkinitcpio runs:

#!/usr/bin/env bash

uki="$3"

[[ -n "$uki" ]] || exit 0

key="/etc/secureboot/db.key"

cert="/etc/secureboot/db.pem"

if ! /usr/bin/sbverify --cert "$cert" "$uki" &>/dev/null; then

echo "UKI to sign: $uki"

/usr/bin/sbsign --key "$key" --cert "$cert" --output "$uki" "$uki"

else

echo "UKI already signed, skipping"

fi

Make the script executable and test it with mkinitcpio -P. The hook now signs every new UKI after pacman -Syu. Once Secure Boot is enabled in BIOS, the system boots from the signed image.

Related articles

AntiMalware•Other

Telegram macOS Developer Says 99.9% of Client Code Is Now Written by AI and Suggests Firing Manual Coders

Mike, the developer of the official Telegram client for macOS, stated that artificial intelligence now generates 99.9 percent of the messenger's client code. He argued that programmers who continue writing code manually should be dismissed. In a Telegram discussion, Mike cited the gram.org website as an example created entirely with AI assistance in a single day, with domain support from Pavel Durov. He also described adapting the iOS client for a foldable iPhone Duo overnight using Claude. According to Mike, even designers are now contributing to client code, and 80 to 90 percent of Telegram developers share his positive view of AI tools. When participants raised questions about code quality and security, Mike replied that AI also identifies and fixes vulnerabilities, claiming the resulting code is superior to human-written equivalents. He further announced plans to open a new GitHub repository for the macOS client source code, as the previous repository had not been updated for over a year.

Habr•Other

What Server Logs Reveal About Attackers: Analyzing Suspicious Requests on Linux

Server logs provide critical insights into potential intrusions by recording events from the operating system, SSH authentication, and web applications. The guide explains how to examine Linux system journals with journalctl, review authentication logs on Debian and RHEL systems, and inspect Nginx access logs for unusual HTTP requests. Analysts learn to identify patterns such as rapid failed login attempts using multiple usernames from a single IP address, which may indicate brute-force or automated scanning activity. The article also covers counting the most active IP addresses with awk and sort commands while stressing the need to compare findings against normal traffic baselines. Additional recommendations include logging structured security events in JSON format with fields for timestamp, user ID, resource, and outcome, following OWASP guidelines. The text warns against storing sensitive data like passwords in logs and highlights limitations such as possible log tampering or unsynchronized server clocks. A practical seven-step investigation plan helps responders preserve evidence and verify hypotheses before taking action.

Habr•Other

UserGate Details FPGA Acceleration to Turbocharge Next-Generation Firewalls

UserGate product manager Pavel Molodan explains why adding security features like IDS/IPS, SSL/TLS inspection, and application control turns a high-performance NGFW into a bottleneck. The company outlines four groups of acceleration methods, with a focus on FPGA-based hardware offloading for packet parsing, firewall rules, NAT, and encryption tasks. Research from 254 respondents shows strong demand for these functions in data center B2E segments at 50-200 Gbit/s. Experimental platforms including Katun-2 PCIe cards and the FG system demonstrate concrete gains, such as scaling IDPS from 5 to 90 Gbit/s and achieving 85 Gbit/s firewall throughput on EMIX profiles. FPGA delivers microsecond latency and better energy efficiency compared with CPU-only designs while preserving full NGFW functionality for elephant flows.

Habr•Other

Curator Reveals Detailed Architecture of Its Network Filtering System After October 2026 Outage

Curator published a technical post-mortem analyzing the 38-minute outage that affected its entire traffic filtering network on October 8, 2026. The company operates nine filtering sites across Russia, each containing multiple nodes connected via high-performance switches to upstream providers. Traffic is isolated using two VRF contexts—external for inbound dirty traffic and internal for cleaned traffic—ensuring sequential processing through the protection system. Each node runs a custom Linux kernel firewall and a watchdog service that monitors BGP sessions to detect failures and remove unhealthy nodes from rotation. Centralized configuration management via CControl allows rapid rollout of rules but also introduces systemic risk when faulty changes propagate across all nodes. The post-mortem emphasizes the need for isolation, staged deployments, and independent recovery mechanisms in large-scale filtering infrastructures.