Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 0 articles for you...
102
network securitysecurity techniqueslinux kernelKeylogging in Linux (Part 3): Kernel Techniques for the Keyboard Driver Path
Part 1 covered how Linux keylogging works in user space and why attackers lean on simple hooks or device access to capture keystrokes. Part 2 walked through the GUI layer, showing how the X Server exposes keyboard events long before applications see them. We closed with a promise to move from observing behavior to turning low-level input into usable detection signals.. This part stays inside the kernel. We look at interrupt handlers and notifier blocks because they’re the two points where every keypress passes through, even on modern Linux 6.x kernels with updated routing in the input stack. The original diagram still holds: physical keyboard, motherboard, CPU, kernel driver, then userland. That level of visibility matters on servers with local console or KVM access. It lets security teams tell normal typing from automated or synthetic input that hints at an implant, since the driver path exposes timing and sequence details that never appear in user space. How a Keyboard Driver Handles Input Inside the Linux Kernel A keyboard driver in Linux sits in the path between the hardware and the input subsystem, translating what the device sends into something the kernel can work with. Nothing fancy there, just the layer that makes raw keyboard signals usable higher up. Under that, you’ve got the interrupt side. During boot, the kernel fills the Interrupt Descriptor Table so the CPU knows which routine to run for each interrupt vector. The keyboard line is brought up early. When a key is pressed, the CPU checks the table, jumps into the right handler, and the input path starts from there. Linux 6.x keeps this flow mostly intact, even with changes in how input routing and console handling are wired now. The driver also feeds the notification system. Anything that registers a notifier_block gets a callback on each keyboard event, and the handler receives a keyboard_notifier_param with the fields we actually care about: vc : virtual console tied to the event down : press (1)or release (0) shift : active modifier bitmask ledstate : state of Num Lock, Caps Lock, Scroll Lock value : the decoded key value for the event The diagram we reference tracks that full path from the physical keyboard, through the motherboard and CPU, into the driver, and up into user processes. Seeing the path end to end helps when you’re trying to spot patterns that belong to real users versus something synthetic. Scancodes, Keycodes, and the Keyboard Driver Input Path Scancodes are what the hardware sends. Keycodes are what the kernel uses after translating those signals. Keysyms sit above that and describe what the key actually represents, which can turn into Unicode when the layout supports it. With PS/2 hardware, the driver reads everything through two I/O ports. Port 0x60 holds the scancode the moment the interrupt fires. Port 0x64 is the controller’s command port. The IRQ handler just pulls the byte from 0x60 and treats it as a press or release based on the PS/2 rules. Nothing special, just the raw path the older hardware still uses. The kernel then walks the usual chain: scancode from 0x60 translated to a keycode mapped to a keysym turned into Unicode when possible Along the way, you’ll see a few event types in the notifier system: KBD_KEYCODE for the early keycode events KBD_UNBOUND_KEYCODE when a keycode has no clean mapping KBD_UNICODE when the keysym resolves to a Unicode character KBD_KEYSYM for non-Unicode keysyms KBD_POST_KEYSYM after keysym handling, where the LED state can be inspected USB keyboards follow a different transport, but the kernel normalizes everything into keycodes and higher-level events, so the input path looks the same. It keeps the higher layers from caring whether the signal came from old PS/2 hardware or a modern HID device. Using Keyboard Notifiers in Linux Device Driver Development Keyboard notifiers give you a way to observe keyboard activity without writing your ownIRQ handler. The kernel handles the scancodes, keycode mapping, and modifier state first, then calls anything registered on the notifier chain. It’s useful when you want higher-level events and don’t need to deal with raw port I/O. You’d choose a notifier when the module only needs translated key data. It keeps the code simple because the driver has already done the parsing, and you’re only reacting to what the kernel considers a complete keyboard event. Example Callback static int keyboard_event_handler(struct notifier_block *nb, unsigned long action, void *data) { struct keyboard_notifier_param *param = data; if (!param-> down) return NOTIFY_OK; const char *key = keybuf[param-> value][param-> shift]; printk(KERN_INFO "key: %s\n", key); return NOTIFY_OK; } The keybuf array stores the printable form of each key. The kernel uses the keycode and current shift state to index into it, so letters, digits, punctuation, and special keys all resolve the same way you’d expect. The reference for that translation logic is the kbd_keycode() helper in drivers/tty/vt/keyboard.c . Registering the Notifier static struct notifier_block nb = { .notifier_call = keyboard_event_handler, }; static int __init kb_init(void) { return register_keyboard_notifier(&nb); } static void __exit kb_exit(void) { unregister_keyboard_notifier(&nb); } When Notifiers Make Sense: They deliver keycodes and characters instead of raw scancodes. They avoid IRQ-level complexity entirely. They provide clean access to the modifier and the LED state. The trade-off is losing the timing information you’d get at the interrupt level, but for most monitoring or detection tasks, notifiers are the more practical tool. Capturing Events Through a Keyboard Driver IRQ Handler Sometimes you want to see keyboard input as early as possible, before the driver translates anything.That means hooking the IRQ directly. It’s the point where the controller fires an interrupt, and the kernel hasn’t done any work yet, so you get the raw scancode exactly as the hardware sent it. The flow is simple enough if you lay it out first: Install your handler Read the scancode from port 0x60 when the interrupt fires Hand it off to deferred work so the IRQ path stays short A basic handler for PS/2 hardware ends up looking like this: static irqreturn_t kb_irq_handler(int irq, void *dev_id) { struct kb_state *st = dev_id; st-> scancode = inb(0x60); tasklet_schedule(&kb_tasklet); return IRQ_HANDLED; } The tasklet handles the actual processing, so the interrupt routine doesn’t stall: static void kb_tasklet_fn(unsigned long data) { struct kb_state *st = (struct kb_state *)data; unsigned char code = st-> scancode; /* translate or log the scancode here */ } DECLARE_TASKLET(kb_tasklet, kb_tasklet_fn, (unsigned long)&state); Bringing it online is just a call to request_irq() : static int __init kb_init(void) { int ret = request_irq(1, kb_irq_handler, IRQF_SHARED, "kb_irq", &state); if (ret) pr_err("keyboard IRQ request failed: %d\n", ret); return ret; } Cleanup mirrors the setup: static void __exit kb_exit(void) { tasklet_kill(&kb_tasklet); free_irq(1, &state); } Even though the example uses port 0x60 and a classic PS/2 path, the pattern holds on newer systems too. PS/2 just happens to be the easy example. USB keyboards come in through a different path, but the workflow doesn’t really change. Keep the IRQ handler tight, hand the rest to the tasklet, and look at the scancode there before the driver starts adding its own layers. Deferred Work and Tasklets in Linux Device Drivers A tasklet is just a deferred handler that runs outside the interrupt path. It gives you a place to do the slower work without holding up the IRQ, which is importantwhen you’re dealing with input events that fire quickly. In short, the IRQ handler grabs the scancode and nothing more, then schedules the tasklet. The tasklet reads that stored value, keeps whatever local state it needs, and handles the translation or logging. A basic logger looks like this: static void tasklet_logger(unsigned long data) { struct kb_state *st = (struct kb_state *)data; unsigned char code = st-> scancode; /* maintain shift state, map scancode to text, and log it */ } DECLARE_TASKLET(kb_tasklet, tasklet_logger, (unsigned long)&state); Cleanup is part of the pattern, too: static void __exit kb_exit(void) { tasklet_kill(&kb_tasklet); free_irq(1, &state); } Newer kernels often push developers toward workqueues or other deferred mechanisms, mostly because they’re easier to scale and better suited to threaded designs. Tasklets still serve as a clear example, though. They show the separation between fast interrupt handling and the slower processing that shouldn’t run in the IRQ context. Notifier Chains vs. Keyboard Driver Interrupt Handlers Both approaches work; they just sit at different layers of the input path and give you different kinds of visibility. Notifier chains You see events after the kernel has already decoded the scancode into a keycode or character. They line up cleanly with the console layer and the rest of the input stack, so the code stays simple. Timing is less precise because the hardware work has already happened by the time your callback runs. Good fit when you want readable events without touching low-level details. Interrupt handlers You see the raw scancode the moment the controller fires the interrupt. You have to manage the hardware-facing pieces yourself, including port reads and deferred work. Timing is exact, which can help surface odd patterns from synthetic or automated input. Higher risk if the handler isn’t tight, since a slow IRQ path can cause real instability. In practice, notifiers are easier for day-to-day monitoring or lightweight detection logic because you avoid the hardware churn. IRQ handlers make sense when you need the earliest possible signal or when timing patterns matter, but they come with more overhead and stricter rules about how the code behaves under load. Common Pitfalls in Linux Device Driver Development for Keyboard Input Low-level keyboard hooks fail in predictable ways, mostly because the path is timing-sensitive and hardware-specific. Heavy IRQ handlers: slowing the keyboard interrupt slows other subsystems too, since they’re sharing the same interrupt resources. Logging in IRQ context: printk or tracing calls here can freeze the system under real load. Assuming PS/2 everywhere: USB-only systems, laptops, and VMs route input through completely different stacks. Kernel drift: internal structures change between releases, and out-of-tree modules tied to those details tend to break. IRQ sharing mistakes: handlers that don’t verify device state can interfere with other devices on the line or miss their own events. USB HID differences: USB keyboards package input differently, and their timing profile doesn’t match PS/2, which matters if you’re comparing events across systems. Short, clear misses like these cause the bulk of issues when teams try to work this close to the input layer. Keyboard Driver Source Code Examples You get one keyboard driver module that uses the notifier chain, one that hooks the IRQ path with a tasklet, and a simple Makefile that builds both against the running kernel. These examples are trimmed for clarity here, and the full source files should be reviewed and expanded as needed before use. Notifier-based keyboard driver module /* notifier-based keyboard driver module * - US keymap table * - keyboard_notifier_param handling * - notifier_block registration * - module init/exit * Full implementation goes here. */ IRQ-based keyboard drivermodule /* IRQ-based keyboard driver module * - shared state with last scancode * - keyboard IRQ handler * - tasklet for deferred logging * - module init/exit with request_irq()/free_irq() * Full implementation goes here. */ Makefile for building the keyboard driver modules # Makefile for keyboard driver examples obj-m += keylogger_notifier.o obj-m += keylogger_irq.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean FAQ: Keyboard Driver Behavior and Event Capture in Linux How does a keyboard driver turn hardware input into events the kernel can use? The controller sends a scancode when a key changes state. The keyboard driver reads that byte in the interrupt path, translates it into a keycode, and hands it to the input and console layers, which then expose it to user space. Where does the interrupt handler fit into the input path? It runs first. The handler pulls the scancode from the controller, marks it as a press or release, and defers any heavier work so the interrupt line stays clear. How do notifier chains observe keyboard activity? Notifier chains run after the driver has already interpreted the event. They receive keycodes, modifier state, and occasionally Unicode, which makes them easier to work with than raw scancodes. Are notifier chains stable across modern 6.x kernels? They’ve held up well. Internal details shift between releases, but the notifier interface and the way it hooks into console input remain consistent enough for out-of-tree modules to rely on with minor adjustments. Do notifier callbacks fire in graphical environments? Yes. They run beneath the graphical layer, so both virtual consoles and GUI stacks trigger the same notifier path as long as the system’s keyboard events pass through the standard input subsystem. Can raw scancode patterns be used for detection work? Sometimes. Automated input tends to produceuniform timing and clean, repeated patterns that don’t match normal typing. Looking at scancodes directly gives you that detail, but it also requires more care in the handler. Can key rhythm or timing anomalies signal synthetic input? They can. Human typing has natural variation, while implants or scripted input often produce tightly spaced or perfectly regular intervals. You see those differences more clearly at the IRQ level. When should I use a notifier instead of an IRQ handler? Use a notifier when you want interpreted events and don’t need timing precision. It’s safer, easier to maintain, and won’t interfere with the interrupt path. When does an IRQ handler make more sense? When you need the earliest possible view of the event, or you’re looking for patterns that appear only in raw scancode timing. It’s more work and carries more risk, but it gives you the most detail. Do USB keyboards change how these mechanisms work? The transport changes, but the kernel normalizes everything before you see it. USB HID delivers packets instead of PS/2 scancodes, yet the driver still emits keycodes and notifies handlers in the same way once the event reaches the input layer. . Explore methods to deploy keylogger strategies on Linux for enhanced protection and monitoring of keystroke activities.. Keylogging Techniques, Linux Kernel Events, Keyboard Event Logging, Security Best Practices. . MaK Ulac
Nov 14, 2025
•
102
exploit analysissecurity flawlinux kernelFile Descriptor Exploits: Lessons from BlackHat USA 2022 Presentation
Learn about a File Descriptor vulnerability that was exposed at Blackhat USA 2022, and the lessons we can take away from this discovery. . Brief Overview of File Descriptor Vulnerability that was Exposed at Blackhat USA 2022 “File descriptor or fd is widely used in the Linux kernel. Exporting an fd to user space and importing an fd from user space are very common and basic operations in the Linux kernel. However, we discovered that there are many types of high-risk vulnerabilities lurking in the usage of these operations. We discovered that the usage of fd importing operations in the Linux kernel can be a very vulnerable scenario. Several new types of vulnerabilities were found in the scenario and will be revealed for the first time. We also found that known types of vulnerabilities like type confusion are still widespread in the scenario unexpectedly. Moreover, we found a dozen vulnerabilities in the usage of fd exporting operations in kernels. These vulnerabilities exist in the Linux and Android kernels, affecting millions of devices. A comprehensive overview of vulnerabilities in the usage of fd operations will be summarized and thoroughly disclosed in this presentation.” What is a File Descriptor? A file descriptor is a number used by the operating system of a computer to specifically identify an open file. To put it another way, when a file is opened, the operating system produces an entry to serve as a representation of the file and to hold data about the opened file. Therefore, if your OS has 100 open files, there will be 100 entries somewhere in the kernel. To the kernel, all open files are referred to by File Descriptors. A file descriptor is always a non-negative number. The kernel returns a file descriptor to the process each time we open or create a new file. A table of all active, open file descriptors is kept by the kernel. File descriptors are typically assigned in a sequential order, and the next available file descriptor from the pool is assigned to the file. When a file isclosed, the file descriptor is released and made available for new allocations. Look at the image below for a better description: Essentially, everything is stored in a “table”, or better known as an array. At Blackhat USA 2022, Le Wu showed us a quick overview of how the file descriptor process works: For all operations, whether it be read, write, import, export, etc, there is the array in the Kernel space and the file descriptor within the user space. We will discuss a little further how this entire process can be a vulnerability. Known FD Vulnerabilities: Why File Descriptors? Throughout the presentation, I constantly questioned why File Descriptors? And I was quickly given the answer: CVE-2021-0920 and CVE-2021-0929 . The reason why these are so important is because they exploit vulnerabilities with File Descriptors. CVE-2021-0920 was an exploit for Linux socket syscall 0-day that allowed attackers to remotely root Samsung devices. This issue was initially discovered in 2016 by a RedHat kernel developer and disclosed in a public email thread, but the Linux kernel community did not patch the issue until it was re-reported in 2021. With CVE-2021-0929 , there was a possible way to corrupt memory due to a use after free. This led to local escalation of privilege with no additional execution privileges needed and user interaction was not needed for exploitation. Due to a race condition in the garbage collection system for SCM_RIGHTS, CVE-2021-0920 is a use-after-free (UAF) vulnerability. Unix-domain sockets can send an open file descriptor from one process to another by using the control message SCM RIGHTS. In other words, a file descriptor is transmitted by the sender, and a file descriptor is subsequently received by the receiver from the sender. Reference-counting file structs become more complex due to this handling of file descriptors. The Linux kernel community created a unique trash collection method to take this into account. This garbage collecting system has avulnerability identified as CVE-2021-0920. An attacker can take advantage of the UAF by succeeding in a race condition during the garbage collecting operation. Just as CVE-2021-0920, CVE-2021-0929 also shares between kernel space and user space, which called for concern since a race condition can happen between kernel and user operations. Maybe there are issues in these race conditions? During the presentation, the presenter constructed such race conditions in the fd export and import operations! Results from Test Cases: Case 1 – Export Operations on File Descriptors: Case 2 – Import Operations on File Descriptors: When given a special race condition, an attacker could possibly affect the import/export operation to make the device do certain actions. What Can These Old, Patched Vulnerabilities Do? CVE-2022-28350, which was already considered patched and highly critical, states “Arm Mali GPU Kernel Driver allows improper GPU operations in Valhall r29p0 through r36p0 before r37p0 to reach a use-after-free situation.” Although this was considered patched and fixed, Le Wu, the presenter, found a way to exploit it in two ways: UAF caused by race condition in fd export operation Fd type confusion caused by race condition in fd import operation With this in mind, they succeed in “stealing” privileged files from others! Moreover, If the SELinux is disabled, the unprivileged process used to steal these privileged files will have the ability to read/write the “stolen” privileged file. The exploitation method of “stealing” privileged files from others has been mentioned by Mathias Krause 99 as well. Our thoughts When speaking about the facts of these vulnerabilities and listening throughout the presentation, firstly, we see that GPU drivers are more vulnerable. Examples of vulnerable ones include ARM mali GPU driver, AMD GPU driver, etc. Secondly, the kernel drivers which use the dma-buf interfaces are more vulnerable. Thirdly, because of thepeculiarities of these vulnerabilities, some of them can hardly be found by fuzzers like syzkaller. To overcome the difficulty of finding these vulnerabilities in the usage of fd operations, and to prevent them from happening to begin with, it is important to make sure programmers use best coding practices. With the rise of API attacks and cyber criminals who constantly look for vulnerabilities like these and revisit old vulnerabilities to see what they can find, it is crucial to maintain good practice. I would like to thank Le Wu for the wonderful presentation at BlackHat USA 2022! Check US 22 Wu Devils Are in the File for the full presentation! . At Blackhat USA 2022, researchers revealed serious vulnerabilities in Linux file descriptors that could lead to exploits and unauthorized access to sensitive data. File Descriptor Vulnerabilities, Linux Kernel Security, Blackhat USA 2022, High-Risk Vulnerabilities, Cybersecurity Lessons. . Brian Gomez
Aug 31, 2022
•
102
security advisorysoftware updatesecurity enhancementsOpenwall: LKRG 0.9.0 Release: Major Changes And Security Fixes
Openwall recently announced the release of LKRG (Linux Kernel Runtime Guard) 0.9.0, featuring a host of major changes and improvements, as well as fixes for multiple security bugs. LKRG is a kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. . In an email sent to the LKRG Users List announcing the release of LKRG 0.9.0, Openwall Founder Alexander Peslyak (known by many as “Solar Designer” ) outlines the major changes that have been made between LKRG 0.8.1 and 0.9.0, and explains the significance of these updates: *) Support new mainline kernel versions 5.8 to 5.12 (inclusive) and new stable kernels 5.4.87+ (which include some back-ports from 5.8+) *) Support new RHEL kernels up to RHEL 8.4's (inclusive) *) Support building LKRG in the kernel tree (not only as a standalone module), as a module or linking into the kernel image (see scripts/copy-builtin.sh) *) Support CONFIG_FUNCTION_TRACER with or without CONFIG_DYNAMIC_FTRACE *) Support various CONFIG_OPTPROBES configurations *) Support loading overlayfs[2] after LKRG (e.g., by Docker; previously, the overlayfs[2] module had to be loaded before LKRG for Docker to work) *) "Support" CONFIG_GCC_PLUGIN_RANDSTRUCT (don't monitor SELinux if enabled) *) Explicitly do not support RT kernels *) Fix support for 32-bit x86 (was unintentionally broken in LKRG for ages, but could mostly work on many pre-5.7 kernel and LKRG builds by "luck") *) Fix detection of process user/group ID corruption to cover any unexpected changes (previously, only numerically lower new IDs, as exploits normally use, would be detected - a limitation left over from early LKRG testing) *) Fix logging of WP/SMEP/SMAP violations on systems with SMAP in the "log and accept" mode (previously, one such violation could mute logging of others) *) Add detection of ADDR_LIMIT corruption attacks *) Remove validation of waking-up tasks (drop pint_validate=2) *) Replace execve(2) hooks (instead hook security_bprm_committing_creds and security_bprm_committed_creds, which shortens the race window for exploits) *) Replace ptrace(2) hooks (instead hook security_ptrace_access) *) Simplify UMH blocking and make it compatible with CPA-protected pages *) Simplify and speed up do_exit hook (no need to validate a dying process) *) Many other changes under the hood to make LKRG easier to maintain and debug *) Integrate LKRG with out-of-tree (a tool to assist kernel module testing) *) Integrate LKRG with mkosi (systemd's tool for generating a test boot image) *) Continuous Integration setup: boot tests on GitHub Actions using mkosi (with Ubuntu's release kernels and their daily builds of mainline kernels) As you can see, we had to make changes to support Linux kernels newer than those available at the time of previous release. Almost every major kernel release, and some back-ports too, broke compatibility with LKRG. Since we did not make new LKRG releases, people with those newer kernels were advised (on the LKRG homepage and otherwise) to use our latest code off GitHub, which we tried to keep in a stable state (lately in part through use of Continuous Integration). We also preserved support for all of the old kernels we supported previously (RHEL7, etc.) LKRG 0.8.1 was already smaller than 0.8, and with 0.9 the LKRG source code became a bit smaller again (at least in terms of line count) due to the simplifications we made, despite of significant additions: $ git diff --shortstat v0.8.1..v0.9.0 126 files changed, 3919 insertions(+), 4375 deletions(-) Also, perhaps in part due to our move to GitHub, we started to receive more direct contributions to LKRG development (GitHub pull requests). The fulllist of direct contributors to this release is: $ git shortlog -sn v0.8.1..v0.9.0 67 Adam 'pi3' Zabrocki 15 Solar Designer 12 Mariusz Zaborski 7 Vladimir D. Seleznev 5 0xC0ncord 5 RageLtMan 5 Vitaly Chikunov 2 F0x1fy 1 William 1 disrupttheflow I'd like to specifically highlight the contribution of support for building LKRG in-tree (scripts/copy-builtin.sh and related testing) by RageLtMan and the contribution of mkosi integration and Continuous Integration setup by Vitaly Chikunov. I'd also like to highlight Mikhail Klementev's offer to use his out-of-tree framework, which Adam eventually added the integration for. The announcement also mentions various Linux kernel issues that LKRG principal developer Adam 'pi3' Zabrocki discovered in the development and testing of LKRG: During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers (however, 1 CVE number covers 2 bugs): CVE-2021-3411 - Linux kernel: broken KRETPROBES and OPTIMIZER CVE-2020-27825 - Linux kernel: Use-After-Free in the ftrace ring buffer resizing logic due to a race condition CVE-2020-25220 - Linux kernel Use-After-Free in backported patch for CVE-2020-14356 (affected kernels: 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140) CVE-2020-14356 - Linux kernel Use-After-Free in cgroup BPF component (affected kernels: since 4.5+ up to 5.7.10) I've also found 2 other issues related to the ftrace UAF bug (CVE-2020-27825): - Deadlock issue which was not really addressed and devs said they will take a look and there are not many updates on that. - Problem with the code related to hwlatdkernel thread - it is incorrectly synchronizing with launcher / killer of it. You can have WARN in kernels all the time. CVE-2021-3411 refers to 2 different type of bugs: - Broken KRETPROBE (recently reported) - Incompatibility of KPROBE optimizer with the latest changes in the linker. Additionally, I've also found a bug with the kernel signal handling in dying process: CVE-2020-12826 - Linux kernel prior to 5.6.5 does not sufficiently restrict exit signals However, I don't remember if I found it during my work related to LKRG so I'm not counting it here (otherwise it would be total 8 bugs while 5 of them would have CVE). That's pretty bad stats... However, it might be an interesting story to say during LKRG announcement of the new version. It could be also interesting talk for a conference. The kretprobes and ftrace issues here are of questionable security relevance (this functionality is not exposed for attack under most reasonable threat models), but all of these are interesting bugs. Peslyak welcomes any feedback on this release. In a recent email exchange with LinuxSecurity.com security researchers, Peslyak summarizes the main benefits that LKRG offers users, “LKRG offers best-effort protection against kernel vulnerability exploits with little effort on behalf of the user - no need to configure a policy, etc. - making it especially beneficial for systems that are not expected to be consistently kept up-to-date.” You can download LKRG 0.9.0 lkrg . Are you using LKRG to help secure your Linux system? Have you downloaded LKRG 0.9.0? What are your thoughts? We want to hear! Connect with us on social media: Twitter | Facebook . Openwall unveils LKRG 0.9.0, featuring major updates and essential security patches aimed at bolstering kernel security and overall integrity.. LKRG, Runtime Integrity Guard, Openwall, Linux Kernel, SecurityImprovements. . Brittany Day
Apr 19, 2021
•
102
security practiceskernel securitysystem protectionHow to Secure Your Linux System Against Kernel Threats and Attacks
The Linux kernel is the core component of the Linux operating system, maintaining complete control over everything in the system. It is the interface between applications and data processing at the hardware level, connecting the system hardware to the application software. The kernel manages input/output requests from software, memory, processes, peripherals and security, among other hefty responsibilities. Needless to say, the Linux kernel is pretty important. . However, with power comes great responsibility, and the Linux kernel is no exception to this rule. Kernel security is critical: it determines the security of the Linux operating system as a whole, as well as the security of every individual system that runs on Linux. Vulnerabilities in the kernel can have serious implications for Linux users, and it is extremely important that users stay up-to-date on news and advisories pertaining to kernel security. In this article, LinuxSecurity examines how kernel security has evolved in recent years and how to mitigate your risk as a Linux user. A Brief History of the Linux Kernel The Linux kernel was created in 1991 by Linus Torvalds for his personal computer. Torvalds had no cross-platform intentions for the kernel; however, over the past two decades the Linux kernel has expanded and evolved to support a wider array of computer architectures than any other kernel or operating system. Not long after its conception, Linux began to attract developers, contributors and users worldwide and was rapidly adopted as the kernel for many free software projects, including the GNU Operating System . Intro to Linux Kernel Security Kernel security is a hot topic in the Linux community due to the fact that a large portion of kernel bugs present potential security flaws. For instance, vulnerabilities in the Linux kernel may allow for privilege escalation or create denial-of-service attack vectors. Many of the more severe vulnerabilities discovered in the Linuxkernel result in attacks that can be carried out remotely without any actions taken by the victim. These attacks present a bigger threat than those that require hackers to have a local account. In general, Linux is an exceptionally secure operating system, which can be attributed to the principles of transparency and collaboration upon which the OS was founded. However, as with any OS, security bugs are inevitable. Thanks to a supportive, passionate and active community, a large portion of the vulnerabilities that exist in the Linux kernel are identified and fixed before they become a significant problem. Others slip through the cracks and cause more grief before they are recognized and addressed. While there have been many more security vulnerabilities that have been found and fixed in the Linux kernel than the ones listed below, some of the most notorious bugs that have been discovered and remedied over the years include: CVE-2017-18017: This critical vulnerability, which exists in the netfilter tcpmss_mangle_packet function, is extremely dangerous because of the important role that it plays in filtering network communications by defining the maximum segment size that is allowed for accepting TCP headers. Without these controls in place, users are susceptible to overflow issues and DoS attacks. The flaw impacts versions before 4.11. CVE-2016-10229: This udp.c bug, also affecting versions prior to 4.5, allows remote attackers to execute arbitrary code via UDP traffic, triggering an unsafe second checksum during the execution of a recv system call with the MSG_PEEK flag. CVE-2016-10150: This use-after-free vulnerability affecting Linux kernel versions prior to 4.8.13 allows users to cause a DoS attack. This flaw could also be exploited by hackers to gain privileges. CVE-2015-8812: This severe vulnerability impacting versions prior to 4.5, which was discovered in the drivers of the Linux kernel, enables remote attackersto execute arbitrary code or cause a DoS (use-after-free) via crafted packets. CVE-2014-2523: This serious netfilter vulnerability, which impacts versions through 3.13.6, can be attributed to the incorrect use of a DCCP header pointer. The flaw allows remote attackers to cause a DoS (system crash) or to execute arbitrary code via a DCCP packet that triggers a call to either the dccp_new, dccp_packet, or dccp_error function. Balancing the Risks of Public Bug Disclosure When a kernel vulnerability is identified, members of the Linux community collectively work to fix it. While this collaboration leads to rapid innovation and effective patches, the publication of patch proposals before their inclusion in the mainstream kernel branch does carry some degree of risk. Threat actors could potentially reverse-engineer a zero-day bug using patch proposals shared on the public mailing list. The community does have guidelines in place to mitigate this risk and keep patch proposals in the right hands until a patch is ready. A private mailing list exists for communicating with individual Linux distribution vendors, giving them time to prepare kernel patches in advance of public disclosure. However, the code for a patch eventually has to make it onto the public repositories that contain the source code for the Linux kernel. Greg Kroah-Hartman , a Fellow at the Linux Foundation responsible for the Linux kernel stable releases, explains: “There is no way to ‘hide’ our work or patches as everything we do is released publicly in our trees. So yes, if you really wanted to see what is ‘broken’ in Linux, you ‘just’ watch everything that is merged into the kernel tree as it has hundreds of fixes for problems every week.” This would be a difficult job, but by no means should be written off as impossible for a determined hacker, especially if he or she were to use ‘-next trees’, which collect likely patches for the next mainline mergewindow. Kernel Security in 2019: Current Issues and New Security Features 2019 has been an eventful year for the Linux kernel. While kernel security is never stagnant, some notorious security issues continue to plague the kernel. One example is Intel’s persistent CPU problems , which have led to Meltdown and Spectre security issues . Zombieland v2 , a security hole which allows hackers to gain read access to your data or to hang your system and can also be used against all recent Intel processors including Cascade Lake, is the latest of these problems. Greg Kroah-Hartman, the stable Linux kernel maintainer, recently commented on Intel’s notorious CPU issues, “These problems are going to be with us for a very long time, they're not going away. They're all CPU bugs, in some ways they're all the same problem, but each has to be solved in its own way. MDS, RDDL, Fallout, Zombieland : They're all variants of the same basic problem.” And securing your OS against these attacks as they appear is a tedious process which could result in a significant performance hit. For instance, disabling hyper-threading to protect systems against Zombieload attacks has been shown to decrease performance for certain workloads by 30% to 40% . In the words of a Chinese developer who recently spoke with Kroah-Hartman, “This is a sad talk.” On a brighter note, this past month Linus Torvalds finally approved a new security feature, the Linux Security Module (LSM) , nicknamed “lockdown”, to be included in version 5.4 of the kernel. The purpose of the feature is to restrict various aspects of kernel functionality, prevent modification of kernel code, and lockdown hardware that could potentially generate direct memory addressing, among other security benefits. The feature, which has been in the works since 2010, was engineered by Mathew Garrett as a way to prevent users with elevated privileges from modifying the Linux kernel code. Torvalds was initially opposed tothe idea, stating that it was “nothing more than a means of getting Linux to boot on what would be Windows-only hardware”. However, with the lockdown feature now in place, Torvalds admits that it “gets us much closer to not requiring external patches”. Another key security feature that is currently in the works is Kernel Address Space Isolation . Its implementation could potentially reduce the risk of leaking sensitive data in attacks like L1 Terminal Fault (L1TF), MDS, hyper threading and other vulnerabilities. Kernel Address Space Isolation would, however, increase the complexity of the kernel code and the impact that this would have on performance has not yet been evaluated. How to Protect Your Linux System from Kernel Vulnerabilities: Tips and Best Practices for Administrators and Users While kernel vulnerabilities are often identified and patched fairly rapidly, it is up to users to take responsibility for maintaining a secure Linux system. Some best practices for protecting your system include: Track security advisories Seek out and apply software patches as soon as they are released Update your system frequently - use automatic updates when possible - and don’t forget to reboot your system once the kernel is updated! (Note: Automatic updates are available for Linux and are often easier to set up and run than those available for Windows or MacOS users) When using a stable version, plan ahead and upgrade to the next version before official support is ended Implement proper firewall filtering policies Harden your server against SYN flood attacks Disable direct memory access (DMA) to prevent DMA attacks Create regular backups Set up system monitoring tools to avoid downtime LinuxSecurity.com is a great resource for information on how to secure and harden your Linux system against kernel vulnerabilities. LinuxSecurity also tracks security advisories for thirteenpopular Linux distributions, and has an RSS feed specifically devoted to advisories. Have additional questions about kernel security or how to secure your system that haven’t been addressed in this article? Do not hesitate to contact us . We would love to continue the discussion! . Learn the methods to harden your Linux kernel and safeguard it against significant risks and contemporary exploits.. Linux Kernel Security, Protecting Linux Systems, Kernel Vulnerabilities, Security Best Practices, Linux Security Tips. . Brittany Day
Nov 19, 2019
•
102
firewallsecurity featurepacket filteringLinux Kernel 2.4 Netfilter Enhancements: Secure Packet Filtering Features
In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel. This document explains those changes and tips on how to get started. . The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks. Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall. The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session makes rules simpler and tries to interpret higher-level protocols. Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level. Packet Filtering Intro: Packet filtering, sometimes called filtering gateways or screening routers, is a component of a firewall system that either permits or denies packets from passing through it based on a pre-defined policy. It examines the packet for source and destination information, as well as ports, such as telnet or ftp, and either permits it to pass or otherwise rejects it. For example, a firewall policy (typically called "rules") may be defined to permit incoming http access to a particular host, but deny access from other hosts. The packet simply traverses the list of rules until it matches a pattern -- one that either permits it or rejects it. The advantages of packet filtering are that they are fast, flexible, and inexpensive. A 486 with 16 megabytes of RAM and two ethernet cards can be converted into a packet filtering firewall that can protect a large number of hosts behind it. They also typically provide a good deal of logging information which can be crucial to tracking a potential intruder. The advantage of packet filtering is also one of its disadvantages. The packet filter does nothing to analyize the contents of the packet to determine if there is any malicious content within it. It simply routes based on a predefined set of rules. Another disadvantage is that it operates based on the information contained in the packet header, and can make no decisions based on the user accessing the remote resource. There is no built-in authorization mechanism. The final disadvantage is that while it's flexible, it's also difficult to maintain. Often times on networks with many hosts to protect, the set of rules become unwieldy and difficult to manage. An intimate knowledge of the underlying IP protocols must be understood in order for the firewall to be effective. A misunderstanding of how one of the protocols work, or even an inadvertant configuration change can lead to undesired consequences. This is obviously an issue with any security system, but a misconfiguration could easily go unnoticed. As mentioned in the initial sentence, packet filtering is a component of a firewall system. For a more robust solution, combine packet filtering with an application level gateway program such as squid . Basic Packet Filtering: It's now possible to match on owner, group, system ID, or process ID of a connection, allowing you to matchlocally-generated packets based on who created them. This would be great for restricting outgoing connections on an ISP machine, for example. The packet filtering in 2.2 kernels provided the ability to limit spoofed packets from entering the network. Packets originating on the internal network should not appear to be entering the external firewall interface. The 2.4 kernel expands on this support by providing an 'unclean' extension that checks for such suspicious packets, as well as other types of malformed or non-standard packets, and sends them to the bit bucket. In previous versions of the packet filtering code, it was only possible to determine whether the SYN flag was set, indicating whether or not the packet was an established connection or the beginning of a new connection. The new packet filtering code allows you to filter on specific TCP flags, not just the SYN flag. This permits a much greater level of control over the packets that can enter or leave your network. For example, to examine all six TCP flags, checking specifically for the SYN and ACK flags to be set: # iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK -j DROP Additionally, it is also possible to filter on MAC address. This is used for matching incoming packet's source Ethernet (MAC) address. The ability to match TCP or UDP packets based on a series of source or destination ports is also now available. Previously, a rule could only match a single range of ports. This might be used to set up a filter to block telnet, ftp, and finger, for example: # iptables -A input -t DENY -p tcp --destport telnet,ftp,finger Finally, no longer do return packets appear to be destined for the server itself on input filtering and appear to be originating from the server itself on output filtering. Filtering Modules: Netfilter includes several shared library add-on modules that provide additional functionality not found in previous packet filtering versions. Eachrule target is a separate module, allowing for easy expansion. In addition to the standard REJECT, DENY and ACCEPT, there are several other targets including: TOS: This option adds a "TOS" target, which allows you to create rules in the "mangle" table which alter the Type Of Service field of an IP packet prior to routing. MIRROR: Reverse source and dest and send back out to the sender. MARK: This target allows you to create rules in the "mangle" table which alter the netfilter mark field associated with the packet prior to routing. This can change the routing method and can also be used by other subsystems to change their behavior. MASQUERADE: Masquerading is a special type of NAT and the one most of us are familar with from ipchains. All outgoing connections are changed to seem to come from a particular interface's address, and if the interface goes down, those connections are lost. DNAT: This target specifies that the destination address of the packet should be modified. SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection. REDIRECT: Redirect is another special type of NAT. All incoming connections are mapped onto the incoming interface's address, causing the packets to come to the local machine instead of passing through. This is useful for transparent proxies. For example, to redirect traffic originating from the 192.168.1.0 network destined for the 192.168.1.1 web server to the 192.168.1.100 server, we might run the following command: # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \ -d 192.168.1.1 -p tcp --dport 80 -j DNAT \ --to 192.168.1.100 The iptables extended packet matching modules supply additional capabilities in the form of shared library add-ons and small kernel modules that provide additional functionality. Stateful Inspection: Thenetfilter framework now includes stateful inspection, also referred to as stateful filtering or sometimes dynamic filtering. This connection tracking mechanism provides the ability to associate all the packets of a particular connection with each other. Stateful inspection attempts to interpret the higher level protocols such as NFS, http and ftp. The behavior of the firewall changes based on the information contained in the packet. If the packet contains information in the header that indicates it is part of an existing connection, and it matches a rule that states it's a permissable service, then it is permitted to pass through the firewall. Previous implementations had no way of knowing if a particular connection to one of those ports were associated with a legitimate connection or was an arbitrary connection, as would be the case with a port scan or malicious hack attempt. Many protocols attempt to allocate arbitrary ports for their data to be passed through. Previously there was no alternative but to poke holes in the firewall to allow these arbitrary ports access should there be a connection that requires it at some point during a connection. The new firewalling code allows the firewall to open ports only long enough for that particular packet on an arbitrary port to pass through it. This greatly increases the overall security of the hosts behind it and is a component of nearly every major commercial firewall implementation. At the same time, it also greatly reduces the window of opportunity for blackhats to attempt to pass malicious packets through the firewall, despite the source and destination ports and addresses being known. This allows only packets that are recognised as being part of an established connection to pass, instead of previously only depending on destination address and port. This also helps to thwart an attacker's attempt at using packets with modified headers that would have previously subverted astateless packet filtering firewall. Rules can now be created to base their routing decision on one of the following states: NEW: This packet is trying to create a new connection RELATED: This packet is related to the existing connection, and is passing in the original direction INVALID: This packet doesn't match any connection ESTABLISHED: This packet is part of an existing connection RELATED+REPLY: This packet is not part of an existing connection, but is related to one, such as an ftp-data transfer when there is already an ftp-control session to that host As a simple example, to forward across the firewall interfaces packets that are part of a pre-existing connection might look like this: # iptables -A FORWARD -j ACCEPT -m state \ -state ESTABLISHED,RELATED While stateful inspection provides much better performance than an application gateway such as squid, and also increases the level of protection over a simple packet filter, they can be as deceptively difficult to set up and maintain. It also may potentially require more memory to store the state information than a standard packet filter. Also, unlike application gateways such as squid, a direct connection is still made with the internal hosts which are being protected, exposing them to the exploitable weaknesses present on that host. Address Translation: Network Address Translation (NAT) is the process of converting one or more IP addresses into another IP address. This is most commonly seen through the use of "IP Masquerading" where a home or internal network is translated into an IP address that is routable on the Internet. The new packet filtering code in the 2.4 kernels include a much more robust form of address translation. The 2.4 kernel packet filtering now supports a one-to-one, many-to-one and even many-to-many IP address and port translation. In the simplest case, an internal address may be translated into one that is addressable on the Internet. Previously, this may have been done using something of the form: # ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0/0 This will convert all IP addresses from the 192.168.1.0 network into the address of the external interface of the box it is running on. From there, an entry is made in the internal kernel data structures that tracks the connection and associates it with the particular host from which it originated. This form of proxying is very easy to set up and provides a great solution for internal users with a limited number of Internet-routable IP addresses. While the masquerading support is still functionally equivalent to its predecessors, additional forms of address translation are now available. The new packet mangling code provides additional forms of translation including the ability to translate the source or destination addresses of a packet, the ports associated with the connection, port forwarding and transparent proxying. Suddenly, with the addition of this improved NAT, load-balancing, fault-tolerance and even high-availability become obtainable. Specifically, the following new NAT options are available: DNAT: This target specifies that the destination address of the packet should be modified. This is a great way to load-balance a connection request amongst several destination servers. SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection. REDIRECT: This is a specialized case of DNAT that alters the destination IP address to send the packet to the machine itself. This is useful in circumstances where one wishes to redirect web traffic to a local proxy server, such as squid. Packets that have had either their source or destination addresses translated will then be retranslated on their return trip, so they are sure to be delivered back to the host with the real IP address. So, to develop asimple and inexpensive load balanacing solution, you might use the following to have your firewall redirect some of the traffic to each of the web servers at 192.168.1.100, 192.168.1.101 and 192.168.1.102, as follows: # # Modify destination addresses to 192.168.1.100, # 192.168.1.101, or 192.168.1.102 # iptables -t nat -A POSTROUTING -i eth1 -j DNAT \ --to 192.168.1.100-192.168.1.102 Other modules exist to do application-specific address translation and extensive documentation exists on how to write these modules. Packet Mangling: Packet mangling is the ability to change or modify packets both before they are routed and after routing has been decided, specifically, the PREROUTING and POSTROUTING subtables. Type of Service One example of packet mangling is the ability to prioritize traffic from separate queues, changing the "Type of Service" value in the packet before it is routed on to its final destination. The Type of Service values can be one of the following: Minimize-Delay Maximize-Throughput Maximize-Reliability Minimize-Cost Normal-Service For example, to provide interactive performance to telnet while using ftp at the same time: # iptables -A PREROUTING -t mangle -p tcp --sport telnet \ -j TOS --set-tos Minimize-Delay # iptables -A PREROUTING -t mangle -p tcp --sport ftp \ -j TOS --set-tos Minimize-Delay # iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \ -j TOS --set-tos Maximize-Throughput Logging: Netfilter improves on previous versions by providing the ability to restrict the rate of matches, such as for suppressing extensive log messages, for example when a host makes a number of connections in a predefined interval. This can help to prevent some types of denial of service attacks. The detailed logging that netfilter provides enables a firewall administrator to not only troubleshoot potential system problems, but also to tracka potential intrusion, and correlate it with other systems and events. The example below shows how to reduce the number of packets originating from the 192.168.1.1 host that are logged: # iptables -A INPUT -s 192.168.1.1 -m limit --limit 1/second -j LOG It is also possible to log messages at different log levels and with different prefix notes: # iptables -A INPUT -s 192.168.1.1 -j LOG --log-prefix ' ##Router## ' This will log all traffic originating from the 192.168.1.1 host and prepend the string " ##Router## " to each entry. It produces the following log output: Jan 28 23:18:42 magneto kernel: ##Router## IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=312 TOS=0x10 PREC=0x00 TTL=64 ID=9189 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Additionally, it also provides the ability to log packets based on many other criteria. More information in logging in general (MAC address, etc). A rule such as the following: # iptables -I INPUT -m mac --mac-source 00:60:67:30:AC:E5 -j LOG produces log output similar to the following: Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 Final Notes: In this article we've covered a majority of the new features available in the new filtering code available in the 2.4 kernel. There are a number of other changes that make using the packet mangling code easier than previous versions. Previously, the forward chain only had information on the outgoing interface, making it more difficult todetermine where the packet came from. It's now possible to create packet filter rules independant of interface address. It's no longer necessary to bind a rule with an interface. It's now possible to specify the "in" interface or the "out" interface for basing filtering decisions. Ipchains and ipfwadm modules exist for backward compatibility with the old systems. Note that you can only have one loaded at a time. You can't have ipchains and some new iptables rules. Acknowledgements: I'd like to express thanks to Kevin Fenzi, my Security HOWTO co-author, and Harald Welte, author of much of the documentation we have today on netfilter, for accuracy-checking my document. Thanks to Benjamin Thomas for proofreading. Any errors are either due to transmission problems or fault of my own, though ;) Related Resources: Netfilter Mailing list: Send a message to
Feb 14, 2001
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More