Determining the presence of wireshark

[Karthik Balaguru]

Hi,
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 ?

Thx in advans,
Karthik Balaguru

 

[Rick Jones]

Have you tried SNAT? I noticed it on YouTube last week.
<http://www.snat-project.com/documentation.html>

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.

rick jones

 

[Lew Pitcher]

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

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.

 

[Karthik Balaguru]

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.

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 ?

Thx in advans,
Karthik Balaguru

 

[Stephen]

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 ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.

 

[Karthik Balaguru]

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.

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 ?

Thx in advans,
Karthik Balaguru

 

[Stephen]

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 ?

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.

 

[Karthik Balaguru]

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.

Thx for the RFC. The RFC 1122 does talk about handling broadcasts.
I found the section 3.3.6 very interesting. But, i wonder why do
implementations vary between windows and linux

Karthik Balaguru

 

[PaulusJrLz]

Hi,
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 ?

Thx in advans,
Karthik Balaguru

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.

Junior Lazuardi

 

[Karthik Balaguru]

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.

It seems that the flaw in Linux TCP/IP stack has been fixed in
kernel 2.2.10 as they drop the incoming packets that are not
destined for this ethernet address.

So, there is a tough job to detect the presence of in network
if the sniffer is running on Linux Kernel 2.2.10.

Karthik Balaguru

 

[Karthik Balaguru]

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 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/hack/unix/live/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/1999/att-271/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/tools/unix/sysutils/ifstatus/ifstatus-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 ! ?

Thx in advans,
Karthik Balaguru

 

[Stephane CHAZELAS]

2010-03-20, 01:59(-07), Karthik Balaguru:
[...]

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 ?

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. neped.c
http://www.artofhacking.com/tucops/hack/unix/live/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.

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.

 

[Karthik Balaguru]

2010-03-20, 01:59(-07), Karthik Balaguru:
[...]

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 ?

All those methods assume the interface is configured with an IP
address, or that the system supports IP.

Okay . Yeah, 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 !

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.

:-(
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 ?

Probably same with

sudo ip addr flush dev eth0

:-(
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.

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.

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.

Karthik Balaguru

 

[Karthik Balaguru]

How about running whireshark while hiding from people
who are trying to find people running Wireshark?

I had that in mind !
But, Is it only for that reason ? Are there no other scenarios ?

Thx in advans,
Karthik Balaguru

 

[Karthik Balaguru]

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


No.  A sniffer is totally passive.

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 ?

AntiSniff:
<http://www.nmrc.org/pub/review/antisniff-b2.html>
You may have trouble finding this one.

PromqryUI in DOS and Windowfied versions:
<http://www.microsoft.com/downloads/details.aspx?FamilyID=4df8eb90-83b....>
<http://www.microsoft.com/downloads/details.aspx?FamilyID=1a10d27a-4aa....>
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:
<http://24h.atspace.com/it/security/arpwatch.htm>

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.

--

Thx in advans,
Karthik Balaguru

 

[pk]

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 ?

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.

 

[alexd]

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 ?

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.

 

[Stephen]

2010-03-20, 01:59(-07), Karthik Balaguru:
[...]

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 ?

All those methods assume the interface is configured with an IP
address, or that the system supports IP.

Okay . Yeah, 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 !

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.

:-(
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 ?

at least 4.

1 - you do not pollute a general capture file with crud from the
capture PC (this is generally true - eg on a "real" Sniffer).

It makes figuring out what is going on from scratch easier.

2 - if you are connecting to say a customer network then you do not
get issues with the capture PC trying to join the local M$oft AD
domain, or catching a local propagating net virus.

3. If you run IP on the interface some firewall configs will try to
block IP of various types to "improve" the PC security.......

4. you may not use IP on this network (much more rare recently, but
used to be common)

:-(
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.

You can detect the presence of a device where there is a lower layer
protocol that the device has to actively use to run.

wireless LAN with a sniffer that doesnt understand passive only
wireless mode for example - no idea if that still includes
wireshark.....

note - at this point all you can tell is there is a device present -
not what it is doing.

 

[Rick Jones]

Okay . Yeah, 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 !

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.

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

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

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 ?

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.

rick jones

 

[bod43]

Lots of good Jeff Stuff (TM) snipped

# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060

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.