LinuxQuestions.org - Promiscuous mode detection, apps.

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Promiscuous mode detection, apps. (https://www.linuxquestions.org/questions/linux-security-4/promiscuous-mode-detection-apps-54751/)

Promiscuous mode detection, apps.

Preamble/researched stuff. The difference between how ifconfig and libpcap-based apps set promiscuous mode. Ifconfig and consorts use a flag, ioctl(SIOCGIFFLAGS):

Code:

strncpy(ifr.ifr_name, "eth0";, IFNAMSIZ);

ioctl(sock, SIOCGIFFLAGS, &ifr);

ifr.ifr_flags |= IFF_PROMISC;

ioctl(sock, SIOCSIFFLAGS, &ifr);

while libpcap-based apps "apply" for membership/ use a counter, using setsockopt(), that sets the interface promiscuous mode:

Code:

struct packet_mreq mr;

(muck, muck, muck around, muck, muck, muck around, hey packet, hey packet!)

memset(&;mr,0,sizeof(mr));

mr.mr_ifindex = ifr.ifr_ifindex;

mr.mr_type =  PACKET_MR_PROMISC;

setsockopt(sock, SOL_PACKET, PACKET_ADD_MEMBERSHIP, (char *)&;mr, sizeof(mr))

Question. I'm looking for apps or methods, for *locally* detecting ethernet adaptors promiscuous mode, excluding those using either libnetlink or the SIOCGIFFLAGS ioctl.

TIA for your time.

You've certainly got me confused with that, and I'm guessing everybody else too, lol.

This post is a free bump :) Maybe somebody else will stumble across it..

Most of the usual detection apps seem to use promisc.c (or something similar) which uses SIOCGIFFLAGS. Might want to try looking at some sniffer source code and see if you can find one that's setting the interface to promiscuous mode by some other means. If you find one, you can probably hack it reletively easy enough to detect a promiscuous interface rather than set it.

Thnx for the bump Grim Reaper and thnx Capt_Caveman for the tip.

Test results wanted

If anyone would be so kind to post the results from running (as root of course) these commands I'd be grateful. Please make sure to FIRST shut down ANY sniffing applications. You will need root privileges, tcpdump and (hopefully) /sbin/ip from the iproute2 package to do this test.

If you have one eth device, please run this:
ethchk() { grep /proc/net/packet -ve ^sk; ip link show|grep "[0-9]:.*eth"|cut -d " " -f 1-3; killall tcpdump; }
cat /proc/net/packet | tee ~/logfile
tcpdump 2>&1>/dev/null; ethchk | tee -a ~/logfile
tcpdump -p 2>&1>/dev/null; ethchk | tee -a ~/logfile

Elif you have two or more eth devices, please run this instead:
ethchk() { grep /proc/net/packet -ve ^sk; ip link show|grep "[0-9]:.*eth"|cut -d " " -f 1-3; }
cat /proc/net/packet | tee ~/logfile
tcpdump -i eth0 2>&1>/dev/null; ethchk | tee -a ~/logfile
tcpdump -i eth1 -p 2>&1>/dev/null; ethchk | tee -a ~/logfile
killall tcpdump

else any other libpcap/libnet app that can put the interface in promiscuous mode could do, and if you don't have /sbin/ip that ain't a real problem either.

Unspawn, I don't fully understand what you are trying to accomplish, perhaps you would explain a bit more?

I ran your commands:

root@darkstar:/home/toby# ethchk() { grep /proc/net/packet -ve ^sk; ip link show|grep "[0-9]:.*eth"|cut -d " " -f 1-3; killall tcpdump; }
root@darkstar:/home/toby# cat /proc/net/packet | tee ~/logfile
sk RefCnt Type Proto Iface R Rmem User Inode
dfbc1480 3 10 0003 2 1 65476 0 67
root@darkstar:/home/toby# tcpdump 2>&1>/dev/null; ethchk | tee -a ~/logfile
tcpdump: listening on eth0

129 packets received by filter
0 packets dropped by kernel
dfbc1480 3 10 0003 2 1 65476 0 67
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP>
tcpdump: no process killed
root@darkstar:/home/toby# tcpdump -p 2>&1>/dev/null; ethchk | tee -a ~/logfile
tcpdump: listening on eth0

56 packets received by filter
0 packets dropped by kernel
dfbc1480 3 10 0003 2 1 65476 0 67
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP>
tcpdump: no process killed
root@darkstar:/home/toby# tcpdump 2>&1>/dev/null; ethchk | tee -a ~/logfile
tcpdump: listening on eth0

logfile:

sk RefCnt Type Proto Iface R Rmem User Inode
dfbc1480 3 10 0003 2 1 65476 0 67
dfbc1480 3 10 0003 2 1 65476 0 67
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP>
dfbc1480 3 10 0003 2 1 65476 0 67
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP>
dfbc1480 3 10 0003 2 1 65476 0 67

does this tell you anything?

regards, tobyl

I don't fully understand what you are trying to accomplish, perhaps you would explain a bit more?
I'm testing someone's idea about sniffers and how to trace them.
The idea evolves around being able to select a string and be able to tell it is a sniffer or a promiscuous mode sniffer from reading /proc/net/packet. I just added /sbin/ip to counter that idea.

# cat /proc/net/packet | tee ~/logfile
sk RefCnt Type Proto Iface R Rmem User Inode
dfbc1480 3 10 0003 2 1 65476 0 67
WTF? Something definately went wrong here.
I told you to shut down any sniffers. Hmm. May be a DHCP client/daemon though...

# tcpdump 2>&1>/dev/null; ethchk | tee -a ~/logfile
dfbc1480 3 10 0003 2 1 65476 0 67
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP>
tcpdump: no process killed
This entry is exactly the same as the previous one?
And since "ip" doesn't show the device in promiscuous mode your results are botched, unless your "tcpdump" binary doesn't default to setting promiscuous mode, or you have taken some linux_capabilities away from the system (which I doubt).

Here's one example:

Code:

Nothing loaded.... all is quiet



cat /proc/net/packet

sk      RefCnt Type Proto  Iface R Rmem  User  Inode

/sbin/ip link

3: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP>

5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP>



Now load promiscuous tcpdump

tcpdump -i eth0 2>&1>/dev/null &



cat /proc/net/packet

sk      RefCnt Type Proto  Iface R Rmem  User  Inode

df6b1ba0 3      3    0003  3    1 0      0      295675 

/sbin/ip link

3: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP>

5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP>



Load another tcpdump, but -p

tcpdump -i eth1 -p 2>&1>/dev/null &



cat /proc/net/packet

sk      RefCnt Type Proto  Iface R Rmem  User  Inode

df6a7540 3      3    0003  5    1 0      0      296837

df6b1ba0 3      3    0003  3    1 0      0      295675

/sbin/ip link

3: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP>

5: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP>

Notice for each reference in /proc/net/packet the "important" counters from RefCnt tru User don't change, and they should have...

Btw[0], on a multi-eth box, you shouldn't kill tcpdump when running tcpdump on ethX, and tcpdump -p on ethY.
Btw[1], any tests are still welcome.

I am not running any sniffers
I am running as a dhcp client

root@darkstar:/home/toby# tcpdump --help
tcpdump version 3.7.2
libpcap version 0.7.2

I have not purposely "taken some linux_capabilities away from the system" . (why would I ?)

you can see the commands I ran, and you can see the results.

'fraid you will have to draw your own conclusions. I don't mind helping if i can. so sorry if i botched something....

Thanks for helping out. As you've seen in my reply I already accounted for the DHCP thingie. So, really, no problem.

As for linux_capabilities, thats interesting from a security POV: Google around for "lcap".

I take it then, that as a dhcp client (pppoA) that I am denied the promisc option?

root@darkstar:/home/toby# cat /proc/sys/kernel/cap-bound
-257

You have got me curious now...

I take it then, that as a dhcp client (pppoA) that I am denied the promisc option?
No, you're not :-]

You have got me curious now...
Read the first post of this thread, then http://www.securityfocus.com/tools/1051 or http://packages.debian.org/unstable/admin/lcap.html
For a list of caps, see /usr/src/linux/include/linux/capability.h, note caps 27 and 28 are not in use. If you set cap 22, then prepare pull the cord, cuz nuttin else aint gonna bring it down :-]
Remember Lcap is system-wide, while Grsecurity and LIDS can also set/take away caps on a per-app basis.