Permission to Capture Packets

June 28, 2023 General, Network Tools, Threat Hunting

How Do I Capture Packets if I’m Not Root?

We have a wide range of security tools available to us that know how to read packets from a network interface and display them, analyze them, and/or summarize them. As network administrators these are indispensable; diagnosing many network problems would be almost impossible without that kind of network vision.

That power comes with a security risk. While they’re not as common as a few decades ago, there are still protocols that transmit passwords or other sensitive information with no encryption at all (FTP, TFTP, POP3, IMAP, SNMP, telnet, HTTP basic authentication, …). Simply watching the network wire while one of these clients logs in would give you that password. That’s why only the root or Administrator user can operate packet capture tools.

So what choices do you have when it comes time to capture packets? You can pick any one of the following approaches.

 

As Root or Administrator

The simplest way, on a system where you have root or Administrator privileges, is to log in as that user. root/Administrator has full control over the system and can capture traffic with no restrictions (see “selinux” for an exception to this). You’ll obviously need the root/Administrator key, password, and/or second factor to be able to log in. If you’re already logged in as a non-root user, you can switch to being root by running “su” (substitute user):

$ whoami
jparker
$ su -
Password: 
# whoami
root
You can run any sniffer now.
# tcpdump -qtnp

Notice that the prompt changes from “$” (non-root user) to “#” (root user). When you’re done, the command “exit” will return you to being non-root:

# exit
logout
$

Running programs as root is simple, but discouraged. An exploitable bug in your sniffer would give the attacker full access to the system when run as root. That same bug would be limited in what it could do with the following approaches.

 

Under sudo

A common way of handing out partial root privileges is to give out sudo (superuser do) privileges. There are two steps to this. First, the root user needs to edit /etc/sudoers to list the commands that a given user is allowed to run. Second, that user needs to prepend the command with “sudo<space>”. Let’s go through the steps to allow user “jparker” to run both the tcpdump and tshark (text-based wireshark) programs.

1 – Find the full paths to the required tools. Run:

which tcpdump
which tshark

On my system I get back “/usr/sbin/tcpdump” and “/usr/sbin/tshark”; use whatever your system returns.

2 – As root, edit /etc/sudoers with the command:

visudo

3 – Near the bottom of the file add a line for the jparker user (or edit the existing line if jparker already exists in this file):

jparker ALL=(root) PASSWD:/usr/sbin/tcpdump,/usr/sbin/tshark

4 – Save the changes and exit the editor.

5 – Log in as jparker. Now try to run the tcpdump command under sudo:

sudo tcpdump -qtnp

After entering jparker’s password the tcpdump program will start with root’s privilege to listen on the network interface(s).

6 – If you want jparker to be able to run commands as root without having to type his/her password, you can modify the line in /etc/sudoers slightly:

jparker ALL=(root) NOPASSWD:/usr/sbin/tcpdump,/usr/sbin/tshark

You sacrifice a little security this way – anyone that comes across a terminal where jparker is logged in can now run these two commands without knowing jparker’s login password.

 

sudo for a Group

To grant sudo privileges to an entire group you need to first create the group of users using “groupadd” or “addgroup” and add their usernames on that line in /etc/group. Now, instead of adding a line for a single user in /etc/sudoers, you’ll put in the group name preceded by “%” in /etc/sudoers, like:

%myadmingroup ALL=(root) PASSWD:/usr/sbin/tcpdump,/usr/sbin/tshark

 

Using Linux Capabilities

It may not be appropriate to hand out these privileges using sudo. Another approach is to flag the capture programs themselves to already have these privileges! Effectively, we’re telling Linux: “When this program is run, automatically include the ability to sniff from network interfaces without the user having to do anything special.”

The Linux operating system has this in the form of capabilities; flags that are attached to a file that will grant one or more root level abilities when that file is run. We’ll use the CAP_NET_ADMIN and CAP_NET_RAW capabilities as both are required to capture packets.
First, run:

getcap /bin/false

If you get something like “command not found”, you’ll need to install the “libcap” binaries first. (Note, “libcap” is for linux capabilities, “libpcap” is needed for packet capture.)
#Debian/Ubuntu

sudo apt install libcap2-bin

#Suse

sudo zypper install libcap-progs

#Fedora/Centos/RHEL

sudo yum install libcap

Now we apply those flags to any packet capture tool(s) we want to run as non-root. You’ll need to run the following command as root or under sudo:

setcap cap_net_raw,cap_net_admin=eip $(which tcpdump) $(which tshark)

Confirm with:

getcap $(which tcpdump) $(which tshark)

Every time you run either tool it will automatically give you permission to capture packets without having to switch to root privileges at all.

If you’re wondering why we have capabilities when we already have sudo, consider this. When you run a command under sudo, you’re giving that command full root privileges, which include:

  • Reading from, writing to, changing ownership of, or deleting any file on the system
  • Capturing packets from a network interface
  • Killing processes belonging to any user
  • Making device nodes (which can get around disk security)

By using capabilities and only handing out the minimum permissions needed to do a task, we reduce the risk compared to handing out full root privileges.

If you later patch your system and install a new version of one of these tools, you’ll need to re-apply the capabilities using the setcap command.

 

Capabilities for a Group

To hand out these privileges to more than one person at a time, you need to first create the group of users using “groupadd” or “addgroup” and add their usernames on that line in /etc/group. Next, modify the permissions, ownership, and access of these tools:

sudo chown root.myadmingroup $(which tcpdump) $(which tshark)
sudo chmod 750 $(which tcpdump) $(which tshark)
sudo setcap cap_net_raw,cap_net_admin=eip $(which tcpdump) $(which tshark)

This changes the ownership of the sniffers so that only the root user and the people in the myadmingroup group can access them at all (the “7” and “5” in “750”). No other users can access them at all.

You’ll need to do this for every packet capture program that you want to run as non-root. You’ll need to rerun these setup command(s) if you upgrade one of the sniffer tools when patching the system.

 

setuid – Giving Full Root Privilege When Running a Program

Before capabilities were introduced, there was one other way of telling the system “When I run tcpdump I want it to automatically run with full root privileges.”, called setuid. To use this old approach, add the setuid flag to the program in question:

chmod u+s $(which tcpdump) $(which tshark)
ls -al $(which tcpdump) $(which tshark)
-rwsr-xr-x. 1 root root 1331320 Feb 10 18:14 /usr/sbin/tcpdump
-rwsr-xr-x. 1 root root 336040 Mar 4 2022 /usr/sbin/tshark

The “s” flag that replaces the first “x” means the program is still executable, but when it runs the program will run as the user that owns it (root, in almost all cases).

While you can still use this approach, use capabilities instead – it’s much safer to hand out just what the program needs instead of full root privileges.

 

Read Packets From a File

You will find that in some environments it is not possible to hand out permission to capture traffic – no matter how finely you hand out this privilege. In those environments you may simply have to say “how can this person accomplish a particular task without direct network capture?”

The packet capture library used in most operating systems (“libpcap/winpcap”) supports both reading packets from a network interface and reading packets from a file that was created earlier (a “pcap” file, commonly with an extension of “.pcap” or “.pcapng”.) Remember that reading from a network interface looked like:

sudo tcpdump -i eth0 -qtnp

To read packets from a file we need to capture those packets in advance.  Find a user with permission to do so and a location where you are able to capture traffic and save the raw packets to a file like this:

sudo tcpdump -i eth0 -qtnp -w networkincident5.pcap

Once these packets are saved we can read them in later with a command like:

tcpdump -qtnp -r networkincident5.pcap

We don’t need any special privileges to do this – just the ability to read that pcap file. This can be run by any user, and on a totally different system than the one that originally captured the packets.

There are plenty of sites that offer free pcap files for you to analyze, such as our Malware of the Day series.

 

Additional Notes

Is This Only for Capturing Packets?

Not at all. The above approaches can be used for almost any program that would like to be run as the root/Administrator user (running backups, transferring files owned by another user, partitioning or formatting drive space, etc.). The only part that needs to be customized is the exact list of capabilities to use if you’re taking the “capabilities” approach. To get a list of the available capabilities, run

man capabilities

and pick the right one(s) for the tool you wish to run.

 

selinux

We normally think of the root/Administrator account as having no restrictions at all. If I try to copy 2TB of random data onto my main hard drive, I can do that if I’m logged in as root (and that’s one reason why I don’t stay logged in as root!)

There’s an exception to the “root can do anything!” rule: selinux. selinux is an additional security layer built into the linux kernel as well as a set of rules that put some limits on what even root can do to a system. If you ever try to run a command as root that’s blocked, check to see if selinux is installed and enabled:

$ getenforce
Enforcing

If you get “command not found”, then selinux isn’t even installed, so that’s not the problem you’re seeing. If you get “Permissive” or “Disabled”, selinux is not blocking any actions taken by running programs. If you get “Enforcing”, then selinux may be blocking the actions of certain programs. To check, see your system logs – selinux will report any blocks there.

 

References

 

 

 

Interested in threat hunting tools? Check out AC-Hunter

Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!

Share this:
Tags:
AC-Hunter Datasheet
GET THE PDF
AC-Hunter Personal Demo
SCHEDULE HERE
What We’re up To

SUBSCRIBE

Recent Posts
Categories
Archives