UserGate Details FPGA Acceleration to Turbocharge Next-Generation Firewalls
UserGate has published a detailed technical overview of hardware acceleration techniques designed to maintain full next-generation firewall performance when multiple security functions are enabled.
Product manager Pavel Molodan compares a fully loaded NGFW to a sports car whose engine power is gradually consumed by accessories. Basic L4 filtering delivers high throughput, yet enabling stream antivirus, IDS/IPS, SSL/TLS inspection, application control, and content filtering quickly reduces effective bandwidth and increases latency.
The article identifies four acceleration categories: hardware methods (ASIC, FPGA, SmartNIC, SSL offload), software-architectural approaches (DPDK, eBPF), system-level scaling (clustering), and policy optimization. FPGA was selected for its reprogrammability, allowing updates for new protocols or attack signatures without replacing hardware.
Inside the FPGA a processing pipeline replaces sequential CPU handling. While one packet undergoes IDPS inspection, another can be decrypted and a third can have firewall rules applied in parallel. The first packet of a new session is still evaluated by the CPU; subsequent packets follow the hardware fast path once a flow rule is installed.
Two experimental platforms illustrate the results. The Katun-2 PCIe card adds 10 Gbit/s of IDPS capacity per module. On platform F, six cards raise throughput from 30 Gbit/s to 90 Gbit/s. The FG platform, sharing the same CPU as the D250 but equipped with a 500 000 LUT FPGA, achieves 85 Gbit/s firewall on EMIX traffic, 150 Gbit/s L4 UDP performance, and more than 90 000 connections per second.
Additional benefits include sub-microsecond latency for database replication and high-frequency trading, plus significantly lower power consumption: an FPGA handling 100 Gbit/s uses roughly 45 W versus 450 W for dual-CPU servers.
Related articles
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.
Secure Boot on Arch Linux: Enabling Protection for UKI Without Replacing Factory Keys
A detailed guide explains how to configure Secure Boot on Arch Linux for Unified Kernel Images without replacing the motherboard's factory keys or relying on Microsoft certificates. The author chose the minimal-intervention approach of adding a custom key to the existing DB section via the UEFI interface instead of using sbctl enroll-keys or shim. The process begins with backing up existing keys to a FAT-formatted USB drive directly from the BIOS menu. New keys are then generated using sbsigntools and openssl, converted to DER format, and enrolled through the ASUS Prime 790-P UEFI interface. A post-hook script for mkinitcpio automatically signs the UKI after every kernel update, ensuring the entire unified image remains protected. The method preserves the original Microsoft and vendor certificates while adding only the user's own signing key.
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.
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.