Platform-Specific information about capture privileges

Platform-Specific information about capture privileges

You need to run Wireshark or TShark on an account with sufficient privileges to capture, or need to give the account on which you're running Wireshark or TShark sufficient privileges to capture. The way this is done differs from operating system to operating system.

To be secure (at least in a way), it is recommended that even an administrator should always run in an account with (limited) user privileges, and only start processes that really need the administrator privileges. The Security page provides explanations why this is a good idea.

Containers

If you are running inside a container, make sure the host allows the container to have sufficient privileges. Note this is in addition to granting privileges to dumpcap and the user within the container. For Linux containers, that means that the container needs the same [CAP_]NET_RAW and [CAP_]NET_ADMIN capabilities that dumpcap is granted in the general Linux instructions below. For the best security, grant only those two capabilities, rather than giving the container full privileges. Some containers, like Docker, provide the NET_RAW capability by default, but few if any provide NET_ADMIN by default. Here are a few examples of how to add capabilities with different container services:

Docker --cap-add=NET_ADMIN --cap-add=NET_RAW
Docker Compose
```
cap_add:
  NET_ADMIN
  NET_RAW
```

Kubernetes

spec:
  containers:
  - name: my-capture-container
    …
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "NET_RAW"]

Podman --cap-add=NET_ADMIN --cap-add=NET_RAW
Podman Quadlet AddCapability=CAP_NET_ADMIN CAP_NET_RAW

Flatpak

Flatpak is not just a packaging mechanism; the Flatpak environment is also a sandbox and, unfortunately, that sandbox does not allow packet capture, so if you're running a Flatpak package for Wireshark, it will only be able to read existing capture files, and possibly capture traffic in an extcap - it will not be able to capture on a network ada adapter.

Virtual machine

If you are running inside a virtual machine, make sure the host allows you to put the interface into promiscuous mode.

Windows

The NPcap or WinPcap driver (called NPF) must be loaded to capture live data. This requires administrator privileges. Once the driver is loaded, every local user can capture from it until it's stopped again, unless the driver was installed limited to Administrator privileges (this is supported by NPcap but not WinPcap).

On recent versions of NPcap (since NPcap 0.993 (2019-04-27) the driver is loaded at boot time to avoid a 90 s loss of network connectivity on Windows 10 and later. On WinPcap, or earlier versions of NPcap, the driver is loaded on demand by Wireshark when it starts to capture live data.

Note: Simply stopping Wireshark won't stop the WinPcap driver!

It might not be desirable that any local user can also capture from the network while the driver is loaded. NPcap provides an option to restrict the driver's access to Administrators only. If this is used, a helper binary, NpcapHelper.exe, will present the user with UAC prompt(s) when Wireshark is started. The WinPcap driver does not support this; see this note in the WinPcap FAQ.

There are four possible solutions to start Wireshark with the privilege to capture:

Start Wireshark as Administrator

Advantage: Very easy to work with.

Disadvantage: It's very insecure running Wireshark this way as every possible Wireshark exploit will be running with the administrator account being able to compromise the whole system.

Start the NPF driver automatically at system start

This is the default on recent versions on NPcap. On earlier versions of NPcap, or on WinPcap, the easiest way to do this is to select Start WinPcap service "NPF" at startup in the Wireshark installer. You can change the start settings of the NPF service to "automatic" or "system" at any time using the following methods:

From the Device Manager you can select View->Show hidden devices, then open Non-Plug and Play Drivers and right click on NetGroup Packet Filter Driver. In the driver properties you can set the startup type as well as start and stop the driver manually.
From the command line you can run
```
    sc config npf start= auto
```
(This must be run as Administrator under Vista.)
In the registry you can change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NPF\Start from 0x3 (SERVICE_DEMAND_START) to 0x2 (SERVICE_AUTO_START) or 0x1 (SERVICE_SYSTEM_START).

As the driver is already started you can run Wireshark as user all the time if the driver is not limited to Administrator access.

Advantage: Very easy to work with.

Disadvantage: Every local user can always capture live data, unless the NPcap driver is installed limited to Administrators.

Start the NPF driver automatically at system start, limit it to Administrators

Select the Restrict Npcap driver's access to Administrators only option when installing Npcap through the Wireshark installer.

Advantage: Restricts the driver to users with Administrator privileges.

Disadvantage: There can be multiple UAC prompts, particularly on Wireshark 4.2.x and earlier where there is more than one prompt per interface (see issue #15082).

Start the NPF driver by hand

You can start the driver by hand before starting Wireshark and stop it afterwards.

Using Wireshark running in a user account could look like:

Start the NPF driver:

runas /u:administrator "net start npf"

Start Wireshark as a user and work with it, including capturing, until the specific job is finished.

Stop the NPF driver again:

runas /u:administrator "net stop npf"

This can obviously be automated using a batch file.

Advantage: Most secure solution.

Disadvantage: You'll have to enter the password each time you start/stop Wireshark.

Most UNIXes

Wireshark has implemented Privilege Separation which means that the Wireshark GUI (or the tshark CLI) can run as a normal user while the dumpcap capture utility runs as root. This can be achieved by installing dumpcap setuid root. The advantage of this solution is that while dumpcap is run as root the vast majority of Wireshark's code is run as a normal user (where it can do much less damage).

GNU/Linux distributions, Wireshark is installed using a package manager

GNU/Linux distributions usually provide package managers which handle installation, configuration and removal of software packages. Wireshark is provided by several distributions and some of them help in configuring dumpcap to allow capturing even for non-root users.

Debian, Ubuntu and other Debian derivatives

By installing Wireshark packages non-root users won't gain rights automatically to capture packets. To allow non-root users to capture packets follow the procedure described in the Wireshark packaging/debian/README.Debian.

Fedora Linux and derivatives

The Fedora Linux official packages add a wireshark group. You will need to add non-root users to that group in order to capture on local network devices as that user. Follow steps 2 and 3 of the directions below to add a user to that group. The group does not need to be created nor the group membership of dumpcap changed, as that is done already by the official packages.

Arch Linux and derivatives

The Arch Linux official packages add a wireshark group. You will need to add non-root users to that group in order to capture on local network devices as that user. Follow steps 2 and 3 of the directions below to add a user to that group. The group does not need to be created nor the group membership of dumpcap changed, as that is done already by the official packages.

Other Linux based systems or other installation methods

Other Linux distributions may require that you give dumpcap sufficient privileges by hand.

Setting network privileges for dumpcap if your kernel and file system support file capabilities

Ensure that you have installed the necessary tools, such as the setcap command.
sudo setcap cap_net_raw,cap_net_admin+eip /usr/sbin/dumpcap (NOTE: Replace /usr/sbin with /usr/bin in case you receive an error that indicates that dumpcap isn't in /usr/sbin)
Start Wireshark as non-root and ensure you see the list of interfaces and can do live capture.

Setting network privileges for dumpcap if your kernel and file system don't support file capabilities

In this case, you will need to make dumpcap set-UID to root.

chown root /usr/sbin/dumpcap (NOTE: Replace /usr/sbin with /usr/bin in this command and the next command in case you receive an error that indicates that dumpcap isn't in /usr/sbin)
chmod u+s /usr/sbin/dumpcap

Limiting capture permission to only one group

Before setting dumpcap's network privileges (for example, using the file capabilities approach above):

Create the group "wireshark":
```
sudo groupadd -s wireshark
```
Add yourself to the group:
```
sudo gpasswd -a $USER wireshark
```
Re-login to apply the group changes or use newgrp wireshark as the normal user to enter the wireshark group. (Run the groups command to verify that you are part of the wireshark group.)
sudo chgrp wireshark /usr/sbin/dumpcap
sudo chmod o-rx /usr/sbin/dumpcap
(Changing the group will clear file capabilities (or setuid bits), so reset it using setcap as described above.)
Ensure Wireshark works only from a user in the "wireshark" group

BSD (including macOS)

In order to capture packets, you must have read access to the BPF devices in /dev/bpf*.

On BSDs without a devfs, the special files for those devices are on your root file system, and changes to them will persist across reboots. In order to allow yourself, or yourself and others, to capture traffic without running Wireshark as root, either make them owned by you, or make them owned by a group to which you and others to whom you want to give capture permission belong and give that group read access, or, if your BSD supports ACLs on special files, add the users who should have permission to capture to the ACL, with the ACL entry giving them read permission. You will probably need super-user permission to do this.

On BSDs with a devfs (this includes macOS), this might involve more than just having somebody with super-user access setting the ownership and/or permissions on the BPF devices - it might involve configuring devfs to set the ownership or permissions every time the system is booted, if the system supports that; FreeBSD 5.x's devfs does. If the system doesn't support that - macOS's devfs doesn't, you might have to find some other way to make that happen at boot time, such as a command in one of the system rc files, or a startup item or launchd launch daemon in macOS; see the ChmodBPF directory in libpcap 0.9.1 or later for such a launch daemon.

Digital/Tru64 UNIX

Any user can, in principle, capture network traffic. However, no user (not even the super-user) can capture in promiscuous mode on an interface unless the super-user has enabled promiscuous-mode operation on that interface using pfconfig(8), and no user (not even the super-user) can capture unicast traffic received by or sent by the machine on an interface unless the super-user has enabled copy-all-mode operation on that interface using pfconfig, so useful packet capture on an interface probably requires that either promiscuous-mode or copy-all-mode operation, or both modes of operation, be enabled on that interface. You might be able to limit the set of users allowed to capture traffic by changing the ownership and/or permissions of the /dev/pfilt* devices.

Imported from https://wiki.wireshark.org/CaptureSetup/CapturePrivileges on 2020-08-11 23:11:50 UTC