How to block unwanted USB ports on Linux using udev

Learn how to write custom rules in the Linux udev subsystem to prevent unauthorized flash drives, mice, or keyboards from working on your machine.

Marcio Cunha•4 min

Also available in:Português Español

Summary

The udev subsystem monitors hardware events and applies dynamic rules as soon as any USB device connects to the operating system.
Identifying exclusive physical attributes of each hardware component is the first step to creating precise restrictions without breaking essential input devices.
Using the udevadm command allows administrators to inspect detailed properties and collect the parameters needed for accurate blocking rules.
Custom rules prevent corporate data leaks and provide an extra layer of physical security against unauthorized removable media.
Maintaining proper hardware isolation practices complements other protective layers, such as iptables firewall rules and physical access policies.

The role of udev in Linux hardware management

When you plug any device into a Linux computer, the core operating system needs to figure out what that equipment is and how to talk to it. This invisible, dynamic background work is coordinated by the udev subsystem, which acts as a reception manager always alert for incoming hardware. Every time a flash drive, printer, or mouse is connected to a USB port, udev swings into action to create quick-access files within the system's device directory.

In practice, this means we can intercept this exact connection moment to enforce behavioral rules. Want to prevent generic mice or unknown flash drives from working on a sensitive workstation? The udev manager allows us to inspect the factory identity of each part and issue an automatic rejection if the serial number or manufacturer does not match an approved whitelist.

How to discover physical USB device properties

Before building any barrier, we need to know the digital identity of the hardware we want to block or allow. Every manufactured component in the world carries factory-registered traits known as vendor ID, product ID, and a unique serial number. To fish out this precious information, we use a native inspection utility called udevadm directly in the terminal.

By plugging in the unwanted flash drive and running the tracking command in the terminal, the system exposes the entire attribute tree of that electronic object. This is precisely where we separate legitimate gear from intruders. Much like diagnosing slow performance on NVMe drives via terminal to isolate hardware bottlenecks, here we look for specific strings like idVendor and idProduct to feed our security rule.

Writing your first custom blocking rule

With the identification numbers in hand, the next step is creating a dedicated configuration file inside the folder where the system reads these directives. These rules follow a simple conditional logic: if the connected device matches specific factory criteria, the system applies a designated action, such as altering access permissions to zero or disabling the corresponding driver.

To put this into practice in a structured way, follow these steps in your terminal with administrative privileges:

Open the terminal and navigate to the system's custom rules directory using the command
```
cd /etc/udev/rules.d/
```
to ensure your modifications remain isolated and won't be wiped out during future core updates.
Create a text file with a specific extension for rules using a text editor like nano by typing
```
sudo nano 99-block-usb.rules
```
to start editing your blocking configuration.
Insert the command line corresponding to your target filter, for example,
```
SUBSYSTEM=="usb", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", ATTR{authorized}="0"
```
and save the file so the core starts ignoring that specific hardware whenever it connects.

Testing and reloading the hardware subsystem

Once the rule file is saved, Linux does not apply the changes magically and immediately; you must tell the system to re-read everything. We do this by asking the hardware manager to reload all active rules into memory. This process is fast and does not require a full machine reboot, saving precious time on servers or corporate workstations.

In practice, the command that updates these directives tells udev to re-examine the bus and apply the new restrictions instantly. As soon as the reload command runs, plugging in the blocked flash drive might cause its LED to flicker with electrical power, but the operating system will simply pretend nothing happened, keeping your data safe against unauthorized copies.

Precautions to avoid locking out your own keyboard or mouse

The great danger of tweaking low-level rules in the operating system is accidentally shooting yourself in the foot, like locking the front door and leaving the key inside. If you write an overly broad rule that blocks the entire USB subsystem without exceptions, your USB keyboard and mouse will stop responding instantly, leaving you with zero ways to interact with the graphical interface or terminal to fix the mistake.

To avoid this operational headache, always build rules focused on specific attributes, such as serial numbers or exact manufacturer combinations. Never apply a global block to the entire controller unless you have remote network access configured to save the day if things go wrong. Testing the rule in a controlled environment or keeping an active SSH session open is a safety precaution just as important as testing a physical component with a multimeter before reinstalling it into a critical circuit.

Final thoughts on physical security in Linux

Blocking unwanted USB ports via udev represents an elegant, inexpensive, and extremely effective defensive layer to protect computers against unauthorized media. While it does not replace cabinet physical integrity or mechanical port locks, this software-driven strategy prevents onlookers from copying confidential files or inserting malicious code through external machine ports.

Understanding how the Linux hardware subsystem works gives us the power to transform a generic system into a rigid, custom-tailored environment. Whether protecting servers in shared racks or client workstations, mastering these basic rules ensures that hardware control returns fully to the system administrator's hands.