What determines an interface's promiscuity, the interface flags or properties?

Question

I was running a scan with Lynis on a RHEL 7 box and it said that an interface was in promiscuous mode. I checked and determined that the links were not based on not having the Promuscuous flag (only Broadcast, multicast, running, and UP (BMRU) are visible):

$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001

$ netstat -i
Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0             9001 17217705      0      0 0      17899485      0      0      0 BMRU

So I looked at how Lynis was checking and it runs the command ip link -o -d show dev eth0 | grep 'promiscuity 1' and sure enough, I find the following:

$ ip -d link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 1 addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535

My question is which is more authoritative. I'm used to just checking the flags and not the interface properties. What does promiscuity 1 mean? Is this interface promiscuous?

Answer 1

As explained in the patch which introduced the promiscuity read-only parameter to ip-link / iproute2:

the flag IFF_PROMISC is exported by the kernel only when the user set it explicitly, for example it will not be exported when a tcpdump is running).

+ if (do_link && tb[IFLA_PROMISCUITY] && show_details)
+     fprintf(fp, "\n    promiscuity %u ",
+         *(int*)RTA_DATA(tb[IFLA_PROMISCUITY]));

And in fact, the dev_get_flags() kernel function which is used by both the ioctl(SIOCGIFFLAGS) interface (as used by ifconfig) and by the rtnetlink interface (as used by ip link show), will explicitly clear IFF_PROMISC from the set of flags exported to userland:

 *      Get the combination of flag bits exported through APIs to userspace.
 */
unsigned int dev_get_flags(const struct net_device *dev)
{
        unsigned int flags;

        flags = (dev->flags & ~(IFF_PROMISC |
                                        ...)) |
                (dev->gflags & (IFF_PROMISC |
                                IFF_ALLMULTI));

[the dev->gflags above is a set of compatibility flags which are not used by the kernel, but only set and retrieved by the userspace interfaces]

The only way to check from the userspace if an interface is in promiscuous mode is (just as ip -d link show does) via the IFLA_PROMISCUITY attribute retrieved via the rtnetlink(7) interface. That reflects the actual promiscuity count of the device: promiscuity > 0 means that the device is in promiscuous mode.

---

Updating the device flags via ifconfig DEV promisc or ip link set dev DEV promisc on is not the only way to set a device in promiscuous mode: another way is via the packet(7) setsockopt() interface:

setsockopt(sock, SOL_SOCKET, PACKET_ADD_MEMBERSHIP, {.mr_type = PACKET_MR_PROMISC})`

That is what tcpdump (and other network capturing and filtering tools) are using.

Answer 2

PROMISCUOUS is a flag by itself, not a combination of others one.

The flag isn't set on the dump you provided.

If i set it on my system manually, i can clearly see it:

~# ifconfig eth0 promisc
~# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 28:f1:0e:09:b8:f8 brd ff:ff:ff:ff:ff:ff
root@NEO-L196:~# ip -o -d link show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\    link/ether 28:f1:0e:09:b8:f8 brd ff:ff:ff:ff:ff:ff promiscuity 1 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
~# 

If you continue getting the warning from Lynis, there's two possibilities:

• Lynis is buggy and reported you a false positive.

• Your system has been hacked and backdoor'ed: the hacker replaced ip, ifconfig and route binaries with patched ones that hide the promiscuous flag.