This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 35 and 36
Revision 35 as of 2008-04-28 05:36:01
Size: 2759
Editor: glookle
Comment: plime-keys2.txt;4;11
Revision 36 as of 2008-04-28 06:03:31
Size: 6625
Editor: UlfLamping
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Platform-Specific information about capture privileges =
Line 2: Line 3:
---- /!\ '''Edit conflict - other version:''' ---- 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.
Line 4: Line 5:
---- /!\ '''Edit conflict - other version:''' ---- 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.
Line 6: Line 7:
---- /!\ '''Edit conflict - other version:''' ---- <<Anchor(windows)>>
== Windows ==
Line 8: Line 10:
---- /!\ '''Edit conflict - other version:''' ---- 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.
Line 10: Line 12:
---- /!\ '''Edit conflict - other version:''' ---- Note: Simply stopping Wireshark won't stop the WinPcap driver!
Line 12: Line 14:
---- /!\ '''Edit conflict - other version:''' ---- 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 [[http://www.winpcap.org/misc/faq.htm#Q-7|this note in the WinPcap FAQ]].
Line 14: Line 16:
---- /!\ '''Edit conflict - other version:''' ---- There are three possible solutions to start Wireshark with the privilege to capture:
 
'''Start Wireshark as Administrator'''
Line 16: Line 20:
---- /!\ '''Edit conflict - other version:''' ---- Advantage: Very easy to work with.
Line 18: Line 22:
---- /!\ '''Edit conflict - other version:''' ---- 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.
Line 20: Line 24:
---- /!\ '''Edit conflict - other version:''' ---- '''Start the NPF driver automatically at system start'''
Line 22: Line 26:
---- /!\ '''Edit conflict - other version:''' ---- 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:
Line 24: Line 28:
---- /!\ '''Edit conflict - other version:''' ----  * '''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.
Line 26: Line 30:
---- /!\ '''Edit conflict - other version:''' ----  * '''From the command line''' you can run {{{
    sc config npf start= auto }}}
 (This must be run as Administrator under Vista.)
Line 28: Line 34:
---- /!\ '''Edit conflict - other version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
 * '''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).
Line 33: Line 36:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
As the driver is already started you can run Wireshark as user all the time.
Line 38: Line 38:
---- /!\ '''End of edit conflict''' ---- Advantage: Very easy to work with.
Line 40: Line 40:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
Disadvantage: ''Every'' local user can ''always'' capture live data.
Line 45: Line 42:
---- /!\ '''End of edit conflict''' ---- '''Start the NPF driver by hand'''
Line 47: Line 44:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
You can start the driver by hand before starting Wireshark and stop it afterwards.
Line 52: Line 46:
---- /!\ '''End of edit conflict''' ---- Using Wireshark running in a user account could look like:
Line 54: Line 48:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
Start the NPF driver:
Line 59: Line 50:
---- /!\ '''End of edit conflict''' ---- {{{runas /u:administrator "net start npf"}}}
Line 61: Line 52:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
Start Wireshark as a user and work with it, including capturing, until the specific job is finished.
Line 66: Line 54:
---- /!\ '''End of edit conflict''' ---- Stop the NPF driver again:
Line 68: Line 56:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
{{{runas /u:administrator "net stop npf"}}}
Line 73: Line 58:
---- /!\ '''End of edit conflict''' ---- This can obviously be automated using a batch file.
Line 75: Line 60:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
Advantage: Most secure solution.
Line 80: Line 62:
---- /!\ '''End of edit conflict''' ---- Disadvantage: You'll have to enter the password each time you start/stop Wireshark.
Line 82: Line 64:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
== Linux ==
Line 87: Line 66:
---- /!\ '''End of edit conflict''' ---- Running Wireshark (or any other network capture/analyzer, for that matter) on Linux needs root privileges. Therefore, you have to have root privileges when starting Wireshark, else you can't capture data. Please note that you don't have to login as root when starting your computer, you can use su(1) or sudo(8) for that purpose. However, this remains unsecure as the dissectors, the parts of Wireshark which parse the captured data, run with root privileges as they did before. A much safer solution would be to su(1) to root, then use the bundled '''dumpcap''' to dump the data (for example, you can evoke dumpcap by using "dumpcap -w ./dumpfile", which will dump the packets to the file "dumpfile" in the current working directory. See "dumpcap -h" for details). You could also use tcpdump for this purpose. The advantage of this solution is, while dumpcap/tcpdump still run as root, you can run Wireshark as a ordinary user and load the data you captured previously, so effectively this is kinda "privilege separation by hand".
Line 89: Line 68:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
== BSD (including Mac OS X) ==
Line 94: Line 70:
---- /!\ '''End of edit conflict''' ---- In order to capture packets, you must have read access to the BPF devices in /dev/bpf*.
Line 96: Line 72:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
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.
Line 101: Line 74:
---- /!\ '''End of edit conflict''' ---- 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.
Line 103: Line 76:
---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo
== Digital/Tru64 UNIX ==
Line 108: Line 78:
---- /!\ '''End of edit conflict''' ----

---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo

---- /!\ '''End of edit conflict''' ----

---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo

---- /!\ '''End of edit conflict''' ----

---- /!\ '''Edit conflict - your version:''' ----
plime-keys2.txt;4;11
----
CategoryHowTo

---- /!\ '''End of edit conflict''' ----
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.

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.

Windows

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.

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

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

Start Wireshark as Administrator

Advantage: Very easy to work with.

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.

Start the NPF driver automatically at system start

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.

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

Linux

Running Wireshark (or any other network capture/analyzer, for that matter) on Linux needs root privileges. Therefore, you have to have root privileges when starting Wireshark, else you can't capture data. Please note that you don't have to login as root when starting your computer, you can use su(1) or sudo(8) for that purpose. However, this remains unsecure as the dissectors, the parts of Wireshark which parse the captured data, run with root privileges as they did before. A much safer solution would be to su(1) to root, then use the bundled dumpcap to dump the data (for example, you can evoke dumpcap by using "dumpcap -w ./dumpfile", which will dump the packets to the file "dumpfile" in the current working directory. See "dumpcap -h" for details). You could also use tcpdump for this purpose. The advantage of this solution is, while dumpcap/tcpdump still run as root, you can run Wireshark as a ordinary user and load the data you captured previously, so effectively this is kinda "privilege separation by hand".

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

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.

CaptureSetup/CapturePrivileges (last edited 2019-10-07 22:56:53 by GeraldCombs)