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

In comp.os.linux.networking Bob <(E-Mail Removed)> wrote:
> 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
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On March 9, 2010 12:40, in comp.os.linux.networking, (E-Mail Removed) wrote:

> On Tue, 9 Mar 2010 08:27:21 -0800 (PST), Karthik Balaguru
> <(E-Mail Removed)> wrote:
>
>>How to determine the presence of wireshark in a network ?
>
> 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.

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o.m>
wrote:
> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
> @usenet01.boi.hp.com:
>
> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
> >> 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,
>
> <SNIP>
>
> > * * 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...
>
> 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

On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
<(E-Mail Removed)> wrote:

>On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o.m>
>wrote:
>> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
>> @usenet01.boi.hp.com:
>>
>> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
>> >> 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,
>>
>> <SNIP>
>>
>> > * * 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...
>>
>> 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 ?

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.
>
>Thx in advans,
>Karthik Balaguru
--
Regards

(E-Mail Removed) - replace xyz with ntl

On Mar 15, 12:13*am, Stephen <stephen_h...@xyzworld.com> wrote:
> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
>
>
>
>
>
> <karthikbalagur...@gmail.com> wrote:
> >On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o.m>
> >wrote:
> >> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
> >> @usenet01.boi.hp.com:
>
> >> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
> >> >> 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,
>
> >> <SNIP>
>
> >> > * * 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 haveany
> >> > * * 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 tothe
> >> > ARP code to verify that the destination MAC was a full broadcast...
>
> >> 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 ?
>
> 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

On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru
<(E-Mail Removed)> wrote:

>On Mar 15, 12:13*am, Stephen <stephen_h...@xyzworld.com> wrote:
>> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
>>
>>
>>
>>
>>
>> <karthikbalagur...@gmail.com> wrote:
>> >On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o.m>
>> >wrote:
>> >> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
>> >> @usenet01.boi.hp.com:
>>
>> >> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
>> >> >> 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,
>>
>> >> <SNIP>
>>
>> >> > * * 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...
>>
>> >> 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 ?
>>
>> 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 ?
>
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 in advans,
>Karthik Balaguru
--
Regards

(E-Mail Removed) - replace xyz with ntl

On Mar 17, 2:09*am, Stephen <stephen_h...@xyzworld.com> wrote:
> On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru
>
>
>
>
>
> <karthikbalagur...@gmail.com> wrote:
> >On Mar 15, 12:13*am, Stephen <stephen_h...@xyzworld.com> wrote:
> >> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
>
> >> <karthikbalagur...@gmail.com> wrote:
> >> >On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o..m>
> >> >wrote:
> >> >> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
> >> >> @usenet01.boi.hp.com:
>
> >> >> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
> >> >> >> 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 ityou can
> >> >> > * * check if a host on your network is running a sniffer (well,
>
> >> >> <SNIP>
>
> >> >> > * * 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 changeto the
> >> >> > ARP code to verify that the destination MAC was a full broadcast....
>
> >> >> 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 ?
>
> >> 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 ?
>
> 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

On Mar 9, 11:27*pm, Karthik Balaguru <karthikbalagur...@gmail.com>
wrote:
> 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

On Mar 17, 2:09*am, Stephen <stephen_h...@xyzworld.com> wrote:
> On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru
>
>
>
>
>
> <karthikbalagur...@gmail.com> wrote:
> >On Mar 15, 12:13*am, Stephen <stephen_h...@xyzworld.com> wrote:
> >> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
>
> >> <karthikbalagur...@gmail.com> wrote:
> >> >On Mar 10, 1:45*am, DanS <t.h.i.s.n.t.h....@r.o.a.d.r.u.n.n.e.r.c.o..m>
> >> >wrote:
> >> >> Rick Jones <rick.jon...@hp.com> wrote in news:hn66ht$h7r$2
> >> >> @usenet01.boi.hp.com:
>
> >> >> > In comp.os.linux.networking Bob <b...@invalid.invalid> wrote:
> >> >> >> 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 ityou can
> >> >> > * * check if a host on your network is running a sniffer (well,
>
> >> >> <SNIP>
>
> >> >> > * * 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 changeto the
> >> >> > ARP code to verify that the destination MAC was a full broadcast....
>
> >> >> 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 ?
>
> >> 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 ?
>
> 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