Re: Rouge APs at Work - How to locate them?!

On Fri, 21 Jul 2006 19:35:50 -0500, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>Not a problem - there are thousands of phrases that translate into
>"stuff happens".

It's really hard to be simultaneously informative, accurate, and
humorous. I can usually do 2 these, but never all at the same time.

>>The problem is to recognize your own access points, from a neighbors
>>access points, and from a rogue access point on the LAN.

>OK - assumption on my part - the only neighbors I can hear at work are
>so far down in the mud that I need a 36 inch dish just to know that
>they exist. At home would be another matter, but nothing is really that
>strong either.

A friend has a customer that just bought a wireless intrusion
detection system. They're in a big glass and steel skyscraper that
faces another similar building. The wireless probe barfs at 127
SSID's or MAC's (not sure which yet), all from the neighboring
building.

I did a quick read of wireless IDS systems and found these articles:
| http://www.networkcomputing.com/chan...leID=189400826
| http://www.networkcomputing.com/chan...leID=189500017
The 2nd URL is a review of various Wireless IDS systems. The articles
didn't say much about how the various IDS systems operated or what
tests were performed, but did include this tibit:
| http://www.networkcomputing.com/chan...9400826&pgno=6
"One method vendors identify whether an unauthorized AP is on the
wired network by sending Layer 2 broadcast messages on the wired
side to see whether the AP repeats that traffic into the air. If
the AP does so, wireless sensors pick up the traffic and identify
the rogue's Layer 2 network."

>I'm going to have to play with this, as the (very limited) testing I've
>done didn't work this way. The broadcasts (ARPs, pings, _everything_)
>were ignored. Minor problem, I don't own/control either the lapdogs or
>the access point, so I'm working from external indications.

My guess(tm) is that some of the other methods used for these wireless
IDS products are somewhat similar (or identical) to the timing idea.
IT's basically a signature analysis or comparison. I'm not sure it
will work because all that's required to wreck the signature is to
enable packet fragmentation in the access point. What goes in via
ethernet, does not resemble what gets transmitted. I suppose only
packets smaller than the fragmentation threshold could be compared,
but that would greatly complicate the pattern matching.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>It's really hard to be simultaneously informative, accurate, and
>humorous. I can usually do 2 these, but never all at the same time.

Go for informative and humorous. Accuracy will take care of itself.
Hobgoblin of little minds and all that...

>all that's required to wreck the signature is to
>enable packet fragmentation in the access point.

Couldn't you deconvolve the packet fragment bits and make a guess
there? Also, packets from the wireless side will always be under the
fragmentation threshold, won't they?

On Sat, 22 Jul 2006 10:51:30 -0400, William P.N. Smith
<news2006c@compusmiths.com> wrote in
<5ie4c2t47p1stu1flj4rh1aj1qnjthjs0c@4ax.com>:

>Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>>It's really hard to be simultaneously informative, accurate, and
>>humorous. I can usually do 2 these, but never all at the same time.
>
>Go for informative and humorous. Accuracy will take care of itself.
>Hobgoblin of little minds and all that...

Gack! My personal preference is informative and accurate, adding as
much humor as possible. Second choice would be accurate and humorous.

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

John Navas <spamfilter0@navasgroup.com> wrote:
>William P.N. Smith <news2006c@compusmiths.com> wrote:
>>Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>>>It's really hard to be simultaneously informative, accurate, and
>>>humorous. I can usually do 2 these, but never all at the same time.

>>Go for informative and humorous. Accuracy will take care of itself.
>>Hobgoblin of little minds and all that...

>Gack! My personal preference is informative and accurate, adding as
>much humor as possible. Second choice would be accurate and humorous.

I rest my case. Thanks for helping me out, John. 8*)

William P.N. Smith <news2006c@compusmiths.com> hath wroth:

>>all that's required to wreck the signature is to
>>enable packet fragmentation in the access point.

>Couldn't you deconvolve the packet fragment bits and make a guess
>there? Also, packets from the wireless side will always be under the
>fragmentation threshold, won't they?

So much for my accuracy. I was thinking that the probes would not
bother to decode the 802.11 over the air packets and not reassemble
them back into 802.3 packets. If I were to compare the LAN side
ethernet packets sizes and timing, with a low fragmentation threshold
set on the rougue access point, there would be no match. However, if
I un-encapsulated the 802.11 packets back into 802.3 ethernet, the
packet sizes would be the same as the LAN side making matching
possible.

If encryption is enabled on the rogue, it's normal for the wireless
client to NOT reassemble packets. No encryption key, not data on the
client side ethernet. However, if one doesn't care if the ethernet
payload is total garbage, a match could be made. I suspect that this
is one reason why wireless IDS probe client radios are seriously
customized.

As for how the fragmentation threshold works, you're correct with a
possible complication.

The way it's suppose to work is that the access point only fragments
packets that are above the fragmentation threshold. One would assume
that all packets larger than the threshold get fragmented, but I've
found this not to be the case. One chipset (I forgot which one) has a
nifty algorithm that only fragments packets after it detects a
collision. It also adjusts the fragment size downward depending on
the collision rate. That can be a big win for thruput as fragmenting
packets requires added headers and management frames, which reduce
thruput. No need to fragment if there's no interference. I don't
know if this feature is implemented in bottom of the line wireless
access points. Probably not as I've never seen the necessary settings
in the web based configurations.

Improving WLAN Performance with Fragmentation
http://www.wi-fiplanet.com/tutorials...le.php/1468331

Oh-oh, I forgot to add some humor. I guess you'll have to settle for
accuracy.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>I was thinking that the probes would not
>bother to decode the 802.11 over the air packets and not reassemble
>them back into 802.3 packets.

I was thinking you could (for instance) see a 1000 byte packet on one
side and a 750 byte packet followed by a 250 byte packet on the other
side (given a 750-byte MTU) and deduce one from the other. [Yeah,
plus or minus extra headers and such.]

>The way it's suppose to work is that the access point only fragments
>packets that are above the fragmentation threshold.

I've seen "automatic" on Linksys products, but that may mean 'ask the
downstream router what it's MTU is'...

>Oh-oh, I forgot to add some humor. I guess you'll have to settle for
>accuracy.

Durn, I hate it when that happens. 8*)

On Sat, 22 Jul 2006 14:37:50 -0400, William P.N. Smith
<news2006c@compusmiths.com> wrote:

>Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>>I was thinking that the probes would not
>>bother to decode the 802.11 over the air packets and not reassemble
>>them back into 802.3 packets.

>I was thinking you could (for instance) see a 1000 byte packet on one
>side and a 750 byte packet followed by a 250 byte packet on the other
>side (given a 750-byte MTU) and deduce one from the other. [Yeah,
>plus or minus extra headers and such.]

At that point, one might as well reassemble the entire packet. The
802.11 fragmentation flag can be checked and byte sizes added until
the fragmentation flag is dropped. Either way, it would require
custom firmware as the Ethernet port on the client or probe would
normally not show any data if the sniffed packets were encrypted and
the probe didn't have the key.

>>The way it's suppose to work is that the access point only fragments
>>packets that are above the fragmentation threshold.
>
>I've seen "automatic" on Linksys products, but that may mean 'ask the
>downstream router what it's MTU is'...

Different fragmentation. That's for the Ethernet side, specifically
the WAN side of the router. There are still some problems with MTU
discovery and black holes. MTU is similar to 802.11 fragmentation
threshold, except that fragmentation threshold refers to wireless
packets, while MTU refers to Ethernet packets.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 jeffl@comix.santa-cruz.ca.us
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

On Sat, 22 Jul 2006, in the Usenet newsgroup alt.internet.wireless, in article
<odj4c2l4gfgniuvg4nab6ifvp2bbkb3tna@4ax.com>, Jeff Liebermann wrote:

>So much for my accuracy. I was thinking that the probes would not
>bother to decode the 802.11 over the air packets and not reassemble
>them back into 802.3 packets. If I were to compare the LAN side
>ethernet packets sizes and timing, with a low fragmentation threshold
>set on the rougue access point, there would be no match.

Let's stop right here for a moment. Think of two kinds of connections.
In the first, the rogue system is talking over the air to the box that
is hosting the rogue access point. Packets only over the air - maybe
encrypted - nothing to compare out onto the Ethernet.

Now the second type of connection is where the user of the rogue system
decides to check the mail, or view his favorite pr0n site or something.
It doesn't matter if the entire packet is encrypted in 4096 bit AES or
double encrypted in ROT-13 or anything in between. Every time he sends a
packet over the air, there is another packet on the wire. He stops, the
Ethernet packets stop. Can you hear those alarm bells? Now if we're
suspicious enough (and at this point, that's a given), we're now snarfing
_everything_ off the air and off the wire. Hmm, the rogue access point
just sent a packet to the rogue system... and 10-30 msec earlier, here's
a packet from the {mail|pr0n} server going to... Hey RUBE!!!

>However, if I un-encapsulated the 802.11 packets back into 802.3
>ethernet, the packet sizes would be the same as the LAN side making
>matching possible.

But I don't _need_ an exact match. The timing correlation is enough to
point the finger. Do you expect the system that's hosting the rogue
access point to be randomly holding the packets before forwarding them?
It might, but the delay is going to be a result of how busy the host and
network is, not some magic "bamboozle the watchers" function. The delay
will be in milliseconds at most. Sure, a lot depends on how busy your
wire is, but the eyes are good at detecting patterns, and you can refine
your filtering algorithm fairly quick.

You also have to think - I'm probably using something like tcpdump with
a snaplen of 70 odd packets or so - I'm probably only seeing the IP and
TCP/UDP header. The contents of the entire packet are not of interest
during the reconnaissance stage. Depending on what I'm looking for, I may
not even be seeing the Layer 2 stuff.I'll kick the snaplen up to the MTU
and add a -v or two when I see something, but not before.

Old guy