This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.

Platform-Specific information about capture privileges

You need to run Ethereal or Tethereal on an account with sufficient privileges to capture, or need to give the account on which you're running Ethereal or Tethereal 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.

BSD (including Mac OS X)

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 Ethereal 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.

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 peration 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.

Windows

The WinPcap driver (called NPF) is loaded by Ethereal when it starts to capture live data.

This loading requires administrator privileges. Once the driver is loaded, every local user can capture from it until it's stopped again.

Note: Simply stopping Ethereal 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, but this can't be currently circumvented. Please note that this is not a limitation of the Ethereal implementation, but of the underlying WinPcap driver; see [http://www.winpcap.org/misc/faq.htm#Q-7 this note in the WinPcap FAQ].

There are three possible solutions to start Ethereal with the privilege to capture:

Start Ethereal as Administrator

Advantage: Very easy to work with.

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

Start the NPF driver automatically at system start

The Ethereal installer has an option (default: off) to install the WinPcap driver automatically at system boot. You can also manually change the start settings of the NPF service to "automatic" or "system". A way to do this is changing the registry key 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 Ethereal as user all the time.

Advantage: Very easy to work with.

Disadvantage: Every local user can always capture live data.

Start the NPF driver by hand

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

Using Ethereal running in a user account could look like:

Start the NPF driver:

runas /u:administrator "net start npf"

Start Ethereal 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 Ethereal.