Determining the presence of wireshark

How to determine the presence of wireshark in a network ?
Are there any specific packet types exchanged while it
is present in the network so that it can be used to determine
its presence in the network . Any tool to identify its presence
in either Windows or Linux ? Any ideas ?

Look for NIC cards and wireless devices running in promiscuous mode.

No. A sniffer is totally passive.

AntiSniff
You may have trouble finding this one.

PromqryUI in DOS and Windowfied versions:
<http://www.microsoft.com/downloads/details.aspx?FamilyID=4df8eb90-83be-45aa-bb7d-1327d06fe6f5&DisplayLang=en>
<http://www.microsoft.com/downloads/details.aspx?FamilyID=1a10d27a-4aa5-4e96-9645-aa121053e083&DisplayLang=en>
Only works for detecting sniffers running on a Windoze system. I
haven't been able to detect DOS, Linux, or Mac sniffers with these
tools.

I've also noticed that most casual users of sniffers running on
laptops like to boot their operating system before firing up their
sniffers. The laptop will usually belch a few DHCP broadcasts and ARP
requests before disappearing into promiscuous mode. These initial
packets can be detected with ArpWatch

The problem is not identifying the presence of the sniffer, it's
identifying which machine is actually doing the sniffing. The MAC
address is a clue, but given the ease of MAC address spoofing, that
information is often useless. Even if I delivered the MAC address on
a silver platter, identifying which one of the potentially hundreds of
similar computers in the room or building might be difficult.

Have you tried SNAT? I noticed it on YouTube last week.

Note that this will present false positives if the NICs in question are
running with "user set" MAC addresses.

With "user set" MAC addresses, the NIC cannot use it's builtin comparison
logic to find frames addressed to the NIC. The OS NIC driver logic has to
match the MAC address on /all/ "on the wire" packets to the "user set" MAC
address, and extract those that match. This requires that the NIC run in
promiscuous mode, to permit the driver access to all the network traffic.

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

One indicator of sniffer activity is a lot of DNS requests from the
sniffer.
This detection is not always effective, since sniffer's DNS resolution
can be turned off.

I'm not sure how robust this:

This action is the one I really like. With the help of it you can
check if a host on your network is running a sniffer (well,
technically your checking if the NIC of that host is running in
promiscuous mode). The idea behind this is to use an arp request
with a forged destination address. First all of let me explain
what is a promiscuous and a normal mode for the NIC. In the first
one the network card simply picks up all of the packets (even
those that are not directed to it), the second mode only picks up
the packets that are directed to it and drops any other
packets. But, all networks cards that work in normal mode will
pick up a packet with the destination address equal
FF:FF:FF:FF:FF:FF (broadcast). So where is the trick ? In a
network with all NICs working in a normal mode if you send an arp
request with the destination address = FF:FF:FF:FF:FF:FE none of
the cards will reply. All of them will simply drop it. But when a
card works in promiscuous mode it will pick up that packets
(remember that it picks up all the packets regardless) and reply
to the request. So when you get a reply from a host after sending
such forged packet it means that the NIC is working in the promisc
mode , so probably a network sniffer is running on that
machine. Let me demonstrate it for you. I'm 192.168.1.6 and the
host I want to check is 192.168.1.8 As usual go to the directory
where you have snat.jar and execute the command (if you have any
problems go here) :

will be. First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

The upshot is it is probably best to ass-u-me that unless you have
complete physical control of your network - all the wires, all the
ports, no wireless - that someone is listening.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

On similar lines, i came across an info that states that due to
a weakness in Linux TCP/IP implementation , it will answer to
TCP/IP packets sent to its IP address even if the MAC address
on that packet is wrong while in promiscuous mode.
But, it seems that the standard behavior is that it will not be
answered because the network interface will drop them as it
is containing wrong MAC address .

I am eager to know Why is the linux implementation different
from that of the standard implementation ? Is it good or bad ?

I think that is how antisniff has been played down
by some snifferes.

I have been searching for these tools that help
in finding the remote systems in promiscuous mode
in a network. I did come across other tools that
help in detection of a system in promiscuous mode
such as the following-

1. Sentinel
Supports 3 methods of remote promiscuous
detection: The DNS test,Etherping test,ARP test.
-a arp test, -d dns test,-e icmp etherping test.
Need to check it out. Has anyone tried this
out ?

2. neped.c
http://www.artofhacking.com/tucops/h.../aoh_neped.htm
Network Promiscuous Ethernet Detector w.r.t Linux-
Specifically designed to detect the sniffers that
use the flaw in Linux TCP/IP Stack !!. I think this
will not be useful for the kernels in which the
flaw has been fixed such as kernel 2.2.10 as they
drop the incoming packets that are not destined
for this ethernet address.

3. promisc.c
http://seclists.org/nmap-hackers/199.../promisc_c.bin
Determines the machine on which it is run is
in promisc mode.
This is similar to "ifconfig -a|grep PROMISC" :-)
But,this does not help remote machine(sniffer)
detection :-(

4. ifstatus
ftp://ftp.cerias.purdue.edu/pub/tool...tus-4.0.tar.gz
Checks and reports the network interfaces on the
system reports any that are in debug or
promiscuous mode - Not suitable for remote sniffer
detection :-(

5. Antisniff
So antisniff appears that it be tricked out if
kernel 2.2.10 is used or if DNS lookup test is
avoided or if the sniffing is not done above an
average network traffic limit. And it seems there
is an equally interesting 'Anti-Antisniff Sniffer'
to play down the antisniff utility :-(

But, I am not sure if Sentinel helps in detection
of remote promiscous mode(Sniffer) even in the
case of linux kernel 2.2.10 ! ?

All those methods assume the interface is configured with an IP
address, or that the system supports IP. There's no need for
implementing an IP stack to sniff ethernet packets. One can use
wireshark on an interface that hasn't got any IP address
configured or that has a firewall rule that prevents it from
emmiting any packet.

sudo iptables -I OUTPUT --out-interface eth0 -j DROP

And that interface will not be detected.

Probably same with

sudo ip addr flush dev eth0

2.2.9 was released in May 1999. I don't expect there be a lot of
pre-2.2.10 Linux boxes around nowadays.

I analyzed it and it appears just like
as you conveyed - Passive Sniffers in promiscuous
modes(Remote) can be detected only if they are on
an interface with a configured IP address !

Interesting to know that wireshark or other sniffers
can be used on an interface that hasn't got any IP
address configured.

But, i wonder what is the advantage/use of running
wireshark on an interface that hasn't got any IP address.
In what kind of scnearios we might need to run wireshark
on an interface without IP address ? Any thoughts ?

It appears that there is NO method to detect passive sniffing
unless the sniffer does not take care of things like hiding
IP address / using a proper flawless OS.

True that there might not be much systems that use pre-2.2.10
unless upgraded. So, it is difficult to determine the presence
of sniffer in networks in such a case.

So, in brief - NO METHOD to detect Passive Sniffing :-(
That is, It seems that unless there is a flaw in the operating
system similar to that of TCP/IP in pre-2.2.10 linux kernel, it
is not possible to determine the presence of sniffers performing
passive sniffing in the network.

Agreed, sniffer is totally passive ! On analyzing various
internet links and also discussions, i understand that
that unless the sniffer does not take care of things like
hiding IP address / there is a flaw in the operating system
similar to that of TCP/IP in pre-2.2.10 linux kernel, it is not
possible to determine the presence of sniffers performing
passive sniffing in the network. The option of using
IPSec for all intranet traffic appears to be the main solution
against passive sniffing.

Though some OS can restrict that only admins can install
certain type of sniffers, i think that is not enough as
sometimes it can be via admin too.
I wonder, why don't the various OS support the detection
of Sniffers so that if a user is running it in the network, the
OS might intimate it to the admins ? Just eager to know ,
is it not possible for the OS to detect a sniffer running on it
and intimate it ?

I think, the various OS(TCP/IP) in network should be
configurable such that if there is a sniffer running on it, it
would be able to intimate to a set of users(admin) in the
network.

The OS here can be either Linux/Windows.
Are there any such tools already available ?

If wireshark is receiving traffic from a mirrored switch port on a separate
dedicated link. You don't need any IP address on that interface.

Let's say you're interested in traffic to/from Host A, but it has no
packet capture mechanism. You have a switch that can do port mirroring
[aka span port] and Host B with two network interfaces. You would mirror
to the spare interface of Host B, and in that case, the spare interface
you're mirroring to would not need an IP address.

Actually, a less contrived scenario [because it was me doing it this
past week] would be trying to work out the network address when the
telco has installed and provisioned a circuit with ethernet
presentation, but despite repeated requests, not given any network
address or subnet mask details. I plugged my laptop into their edge
router, ran 'tcpdump -n -i eth0' and within a couple of seconds I could
see ARP requests for a range of IP addresses. I was thus able to guess
the IP addresses in use on the circuit, and configured the customer's
edge router accordingly.

Or more generally be coerced into emitting some traffic. It does not
have to be IP traffic. If there were a flaw that caused the sniffing
system to respond to an 802.2 XID/Test frame that would be a
non-IP-configured situation.

There is more to networking than is dreamt-of in IP's universe :)

From time to time, to figure-out the MAC address of some new-to-me
device I have connected it to an unused port on some other system,
fired-up a sniffer on that port, and the fired-up the new-to-me
device. Generally I'm looking for the DHCP request so I can get the
MAC to edit my own DHCP server configurations to give the new-to-me
device a specific IP address.

That doesn't really make sense. For sniffing, there is no need for
the sniffer to obtain or fake an IP address. Sniffing is usually done
at Layer 2 or the MAC address layer (although I've sniffed at the
physical layer with an oscilloscope looking for waveform corruption).
Since the passive sniffer is not interested in collecting its own
traffic, there's no need to assign it an IP address. One can
literally cut the transmit ethernet pair on the transceiver and still
sniff. Assorted products (and methods):
<http://www.netoptics.com>
This works:
<http://www.ethereal.com/lists/ethereal-dev/200012/msg00037.html>

Just to make sure you understand, just creating an ethernet tap and
sniffing with Ethereal or Wireshark is not going to give you access to
all the network traffic. You're most likely going to have an ethernet
switch between the internet or a server and your sniff point. You'll
only see the traffic that either has YOUR destination MAC address, or
is a broadcast. Traffic to and from some other workstation is going
to be invisible.

That's not quite true with wireless networks, where you can
theoretically hear everyone. However, that's a bad assumption. If
you want to sniff both sides of wireless traffic, you have to locate
your wireless sniffer in a place where you can hear both radios at the
end points of a link. For point to point links, that's not so easy as
you would need to be along the line of sight. It will work for a hot
spot, where all the radios involved are in an enclosed area, and your
sniffer can hear all of them.

Nope. There's also SSL, dedicated encryption devices, and MAC layer
encryption as found on some ethernet cards (i.e. 3COM 3CR990b).
<http://www.3com.com/products/en_US/detail.jsp?pathtype=purchase&tab=features&sku=3CR990-TX-97>
You can also do application layer encryption. If you really want to
drive a sniffer nuts, try transport layer obfuscation, where the
transceiver injects extra bits of garbage, and the receiving end
removes the extra bits, using some kind of synchronized algorithm such
as GPS clock sync, or a common lookup table. There are plenty of ways
to turn data into garbage, but only a few that will turn garbage back
into data.

In a locked down IT department monitored environment, that might make
some sense. Anywhere else, most users are able to run as root or
administrator with a minimum of effort.

Because approximately 0.00000001% of the computers on the planet need
a sniffing function and NBC (NoBody Cares). A better question would
be why Microsloth intentionally disabled access to the promiscuous and
monitor modes in NDIS 5, while Linux allows it in every network
driver. Hint: Think of a good conspiracy theory.

The OS can easily detect if it the ethernet card on the same machine
is running in promiscuous mode. That's easy because the OS had direct
access to the NIC registers and driver settings. That's not so easy
from outside the computah, where such testing would be considered a
hostile probe attempt.

Sorry, I don't understand that statement. TCP/IP is not an operating
system. An application cannot imitate itself. I have no idea what
you mean by "set of users(admin)". There is no root/admin access
security on the network. Try again.

Make my life easy. What are you trying to accomplish? There are
plenty of tools, but you have not described what you are doing, and
therefore recommending specific applications will probably not fit
your unspecified goal.

Maybe the OP would like Token Ring where if I
recall correctly the protocol required that MACs in
promiscuous mode set the "Monitor Present"
bit in the token (or somewhere - can't be bothered to
check and it's been a while -- and no one cares).

As many people have said there is no way to
guarantee detecting a monitor on the network.

Of course at one time with fiber it was indeed believed
that intrusion was detectable.

The idea was this.

You constantly monitored all connections for service
interruptions. If there was an interruption you sent round
the boys in black to check for network taps just in case
the interruption was caused by someone inserting a tap.

Otherwise the only way of seeing the light was to bend the
fiber sharply which caused leakage. Some one I seem
to recall came up with something that detected that too.
A company I worked at was involved in bidding
such a proposal decades ago. We didn't get the job
(or maybe just no one told me:) and maybe the whole
thing fell through anyway.

Of course all this is only affordable for government level
or similar security.

Then there is quantum cryptography which guarantees
that message interception is detectable by principle.

When I'm getting a promiscuous capture, I want to obtain as accurate
a capture from the channel as is possible (/convenient). Having
my sniffer's IP stack enabled is not helpful in this regard. In
fact, since some operating systems will babble incessantly on any
interface with an IP address, it is downright harmful to accurate
capture.

For example, if I'm trying to measure the 802.11n performance
between one our our APs an a client device, it doesn't do me
any good for my sniffer to be spamming the channel with some
NBNS nonsense at the same time.

I.e. this is just basic test engineering 101: if you're going to
perform an observation, you want the process of observation to be
non intrusive as it can be.

Yeah, sure. If there were only one interruption caused by a tap
insertion, that would probably be cause for an investigation. When
you have a few dozen minor interruptions daily, it's difficult to get
inspired to investigate one more. More likely, the fault will
magically heal itself, and the operator or log skimmer will assume
it's a transient error. If 10G, GFEC (Generic forward error
correction) might mask any errors.

Many of the fibers worth taping are miles and miles long. One big
long dark fiber. How about this run from Santa Cruz to Sunnyvale in
one piece? About 99% of the light never makes it to the other end,
but that's good enough for DWDM (dense wave division mux). A little
additional loss, and probably nobody would notice.

On the other foot, picking up leakage from a bent single mode fiber is
not my idea of fun. I could probably build a suitable pickup, but
trying to get all the different colors separated would be a mess.
Besides, the DWDM sniffer box would probably cost $10,000 and up. Even
so, sniffing fiber is like drinking from a fire hose. The horsepower
required to decode and capture everything is well beyond that of a
common PC.
If you throw an infinite amount of (public) money at a problem,
anything is solvable (except maybe federal health care).

Yep. That's the major benefit.

Wireshark has DNS resolving on by default (or it used to, as
far as I can remember). If the sniffer is an amateur, and leaves it
on, you can try to ping an imaginary address. The sniffer's wireshark
will pick up the address and try to resolve it. So just filter with
"dns and "pinged IP"") and you can see which computer wireshark is on.

Kismet and aircrack of course are MUCH less detectable than
wireshark.......they are totally non intrusive.