This article focuses on Linux and some UNIXes. For Windows users, there is some good info in the Wireshark wiki.
Many network engineers become dismayed the first time they run Wireshark on a Linux machine and find that they don’t have access to any network interfaces. This is because, by default, raw access to network interfaces (e.g. eth0) requires root privileges. Unfortunately, this often prompts people to simply run Wireshark as root – a bad idea. As an older Gentoo Linux ebuild of Wireshark warns:
WIRESHARK CONTAINS OVER ONE POINT FIVE MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.
Indeed, due to the complexity and sheer number of its many protocol dissectors, Wireshark is inherently vulnerable to malformed traffic (accidental or otherwise), which may result in denial of service conditions or possibly arbitrary code execution. But if we shouldn’t run Wireshark with root privileges, how are we to capture packets?
The lead developer of Wireshark, Gerald Combs, points out some that Linux distributions are beginning toimplement Linux filesystem capabilities for raw network access. In this article, we’ll walk through putting this idea into practice on an Ubuntu 9.10 machine, and include a bit more detail behind the system commands.
What are filesystem capabilities? From the man page:
For the purpose of performing permission checks, traditional Unix implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is non-zero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process’s credentials (usually: effective UID, effective GID, and supplementary group list).
Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.
The manual goes on to list over two dozen distinct POSIX capabilities which individual executables may be granted. For sniffing, we’re interested in two specifically:
- CAP_NET_ADMIN – Allow various network-related operations (e.g., setting privileged socket options, enabling multicasting, interface configuration, modifying routing tables).
- CAP_NET_RAW – Permit use of RAW and PACKET sockets.
CAP_NET_ADMIN allows us to set an interface to promiscuous mode, and CAP_NET_RAW permits raw access to an interface for capturing directly off the wire. These capabilities are assigned using the
Enabling Non-root Capture
Step 1: Install setcap
First, we’ll need to install the
setcap executable if it hasn’t been already. We’ll use this to set granular capabilities on Wireshark’s
setcap is part of the libcap2-bin package.
stretch@Sandbox:~$ sudo apt-get install libcap2-bin Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: libcap-dev The following NEW packages will be installed: libcap2-bin 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 17.7kB of archives. After this operation, 135kB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com karmic/universe libcap2-bin 1:2.16-5ubuntu1 [17.7kB] Fetched 17.7kB in 0s (36.7kB/s) Selecting previously deselected package libcap2-bin. (Reading database ... 146486 files and directories currently installed.) Unpacking libcap2-bin (from .../libcap2-bin_1%3a2.16-5ubuntu1_amd64.deb) ... Processing triggers for man-db ... Setting up libcap2-bin (1:2.16-5ubuntu1) ...
Step 2: Create a Wireshark Group (Optional)
Since the application we’ll be granting heightened capabilities can by default be executed by all users, you may wish to add a designated group for the Wireshark family of utilities (and similar applications) and restrict their execution to users within that group. However, this step isn’t strictly necessary.
root@Sandbox# groupadd wireshark root@Sandbox# usermod -a -G wireshark stretch
After adding yourself to the group, your normal user may have to log out and back in. Or, you can run
newgrp to force the effect of the new group (you’ll have to launch Wireshark from this same terminal environment in step 3):
stretch@Sandbox$ newgrp wireshark
We assign the
dumpcap executable to this group instead of Wireshark itself, as
dumpcap is responsible for all the low-level capture work. Changing its mode to 750 ensures only users belonging to its group can execute the file.
root@Sandbox# chgrp wireshark /usr/bin/dumpcap root@Sandbox# chmod 750 /usr/bin/dumpcap
Step 3: Grant Capabilities
Granting capabilities with
setcap is a simple matter:
root@Sandbox# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
In case you’re wondering, that
=eip bit after the capabilities list grants them in the effective, inheritable, and permitted bitmaps, respectively. A more thorough explanation is provided in section 2 of this FAQ.
To verify our change, we can use
root@Sandbox# getcap /usr/bin/dumpcap /usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip
Now, as the user who we added to the wireshark group in step 2, execute Wireshark. You should now see the full list of available adapters and can begin sniffing. (If not, double-check that the wireshark group is listed in the output of
groups. You may need to log out and back in for the new group assignment to take effect.)