On Mar 14, 2011, at 2:55 PM, Semjon wrote:
> But You could check if some nic on the subnet is in prominiscuous mode which
> is quite unusual unless You want to see all network traffic i.e sniffing.
> More info here:
>
> http://cns.tstc.edu/cpate/LINUX/Linux_How2/Sniffers.htm
The first two methods listed there for detecting sniffers assume that packets received promiscuously - i.e., packets that you would not have received had the adapter not been in promiscuous mode - are handled by the network stack in the same way that packets received non-promiscuously; is that the case in current operating systems? At least some of them purport to know how a packet was received - the Linux packet(7) man page:
http://linux.die.net/man/7/packet
says
The sockaddr_ll is a device independent physical layer address.
...
...sll_pkttype contains the packet type. Valid types are PACKET_HOST for a packet addressed to the local host, PACKET_BROADCAST for a physical layer broadcast packet, PACKET_MULTICAST for a packet sent to a physical layer multicast address, PACKET_OTHERHOST for a packet to some other host that has been caught by a device driver in promiscuous mode, and PACKET_OUTGOING for a packet originated from the local host that is looped back to a packet socket. These types make only sense for receiving.
and they might keep promiscuously received packets (PACKET_OTHERHOST, in sll_pkttype on Linux) from getting handed to any part of the networking stack other than the packet-sniffing part (taps in the Linux kernel, BPF in *BSD and Mac OS X, NDIS attachments with a "promiscuous" filter on Windows, etc.).
The third only works if you're logged into the machine running the sniffer and the sniffer is running. The fourth ("Latency Method"; it's tagged as 7 because the numbered sublist in the third item isn't actually a sublist so its items count in the numbering scheme) doesn't seem to be unique to sniffers - all it detects is busy machines, maybe.
