Keywords: npf service
Description: 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
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.If you are running inside a virtual machine, make sure the host allows you to put the interface into promiscous mode.
The WinPcap driver (called NPF) is loaded by Wireshark when it starts 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.
It might not be desirable that any local user can also capture from the network while the driver is loaded, but this can't be currently circumvented. Please note that this is not a limitation of the Wireshark implementation, but of the underlying WinPcap driver; see this note in the WinPcap FAQ.
Disadvantage: It's very unsecure running Wireshark this way as every possible Wireshark exploit will be running with the administrator account being able to compromise the whole system.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.
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).
Start Wireshark as a user and work with it, including capturing, until the specific job is finished.
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 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.
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 /usr/share/doc/wireshark-common/README.Debian
2. setcap 'CAP_NET_RAW+eip 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 )
Setting network privileges for dumpcap if your kernel and file system don't support file capabilities
1. 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 )
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 Mac OS X), 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 - Mac OS X'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 in OS X; see the ChmodBPF directory in libpcap 0.9.1 or later for such a startup item.
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.