1

I am evaluating, how tcpdump can be used in a safer manner with as few as possible privileges. Two possibilities:

1. -Z option

If tcpdump is running as root, after opening the capture device or input savefile, but before opening any savefiles for output, change the user ID to user and the group ID to the primary group of user.

This behavior can also be enabled by default at compile time.

Afaik tcpdump opens the network interface to be sniffed in promiscuous mode and a possible file (-r flag) with root, but changes to user privileges before any further outputting is started.

This should minimize possible attack vectors, as parsing the network traffic and possible malicious network packets is done as unprivileged user. E.g. what about taking user nobody to ensure minimum permissions:

tcpdump -i wlan0 -s 0 -Z nobody src portrange 1-80 

2. setcap

Use setcap to add file capabilities CAP_NET_ADMIN, CAP_NET_RAW to /usr/sbin/tcpdump, as suggested here and here:

sudo su
groupadd pcap
usermod -a -G pcap $USER
chgrp pcap /usr/sbin/tcpdump
chmod 750 /usr/sbin/tcpdump
setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

Comparison

Above solutions seem to be mutually exclusive: -Z option docs state, user switching is only done, if tcpdump is run as root.

Disadvantage I see with solution 2: the malicious code still would have user permission for tcpdump and CAP_NET_ADMIN / CAP_NET_RAW. So I would favor solution 1.

What do you think?

2
  • What do you mean by "safer"? Have you done a Threat/Risk Assessment?
    – waltinator
    Commented Jan 12, 2021 at 20:43
  • @waltinator no, nothing really sophisticated. I guess, the main question is, if my assessment of the -Z option in tcpdump is correct (I am quite new to it). If tcpdump degrades from root to a given user (configured to have minimal permissions) after enabling promiscuous mode and before recording traffic (with potential malicious packets), I wouldn't see any reason bothering with solution 2. Second solution demands extra file capability permissions and tcpdump to be owned by a non root group.
    – A_blop
    Commented Jan 12, 2021 at 22:52

1 Answer 1

2

Your first solution is superior. When tcpdump drops to a non-root user, it also loses the capabilities you listed (along with all others). If you want to limit the damage from any compromised tcpdump process, using -Z is a great start, and much better than running privileged as root.

Note that the nobody user should not be used as a generic "unprivileged" user. This is because everything running as that user will be able to interfere with each other. It's much better to create a new user specifically for tcpdump with all the restrictions you want and drop to that user instead.

If you want further security, you can set it up in a chroot (note that this provides security only if the process is not privileged, otherwise it can escape from the chroot), or mandatory access controls such as AppArmor or SELinux to minimize rogue filesystem access. Rlimits would be smart, too, because some exploits require allocating a lot of resources. An integer overflow in a buffer size that requires allocating 2 GiB of memory to trigger cannot be exploited if RLIMIT_AS is low!

Finally, realize that tcpdump sends a BPF filter to the kernel when it is run. The BPF filter then runs automatically and the kernel only returns packets to tcpdump when the filter matches. Because tcpdump supports a large number of protocols and has complex parsers for each, a strict filter that only matches exactly what you want will make it harder to exploit the code. To monitor ICMP traffic between 10.0.0.1 and any of 10.0.0.0/24, use icmp and host 10.0.0.1 net 10.0.0.0/24 rather than host 10.0.0.1. Both of these will capture ICMP traffic between one host and a network, but the latter could allow an attacker on, say, 10.0.4.6 to exploit a bug in tcpdump's FTP parsing code. While the former won't prevent an attacker from sending the malicious traffic, it will stop the kernel from handing tcpdump the packet and asking it to decode it.

2
  • Thanks, your answer is very helpful - exactly the kind of depth I hoped to read here. Would you consider unprivileged user switching to be an additional, useful hardening operation or is it rather not relevant given chroot, SELinux, rlimits?
    – A_blop
    Commented Jan 25, 2021 at 12:38
  • @A_blop Switching to an unprivileged user is a necessary prerequisite for using things like chroot securely. A privileged process can break out of chroot.
    – forest
    Commented Feb 7, 2021 at 1:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .