Rouge APs at Work - How to locate them?!

On Thu, 20 Jul 2006 10:46:30 -0700, Jeff Liebermann wrote in :

How do you propose to configure that with only one external IP address? If the wired router is connected to the WAN, then the wireless access point connects to a wired router switch port, which means no isolation in most consumer routers. Am I missing something?

I dunno whether this is a fuzzy explanation (it was 9:35PM), or what, but this is confusing to say the least. If I send a broadcast from the wired side, all hosts will receive it, and any of them could be the one that is running the rogue access port and forwarding it over the air. How do I know which one it is? MAC address? (easily set to "something" random). If the access point is in bridging mode, the source MAC will be the box out on the wire that sent the broadcast.

On the other hand, if I try to send the packet from my Acme wireless detecto box into the rogue access point, would it even accept it, much less propagate it?

Wolfgang's idea on the other hand is highly likely to work, unless the rogue host that is accessing the unknown access point is quiet, or is merely sharing with the computer that the access point is in/attached to, or is using that host as a proxy server. If the remote host accesses the wired network, even if the rogue access point is a wireless card in a *nix box doing NAT, or a windoze box doing Internet Connection Sharing, the timing correlation between the wireless transmissions, and some similar packets appearing on the wire will nail it in short order. This would hold true even if the box that had the access point was acting as a proxy server. And the detection concept is trivial to implement. The "hard part" is writing the shell or perl script to correlate the data from the two sniffers. Given that's just a few lines...

Old guy

Fuzzy? I had a really bad day, went home early, and didn't post much in the way of details. Sorry. Explanation follows.

The problem is to recognize your own access points, from a neighbors access points, and from a rogue access point on the LAN. Just sniffing packets is going to be confusing because there's no way to distinguish a rogue access point on the company LAN, from a legitimate neighbors access point. It's a fair assumption that you know the MAC addresses of your own access points. When you send out broadcasts, only your own access points, and the rouge access point(s) will transmit the packets. The neighbors will not. Therefore, anything that is broadcasting these packets, but is not one of the known MAC addresses, is a rogue access point.

It had better accept it or the rouge access point could not be used to surf the local LAN or the internet.

I'll conceed that Wolfgang's comparison idea is kinda nifty and will work. However, the broadcast trick can be implimented without any programming and using conventional sniffers. Also, it doesn't matter if the rouge access point is running Soft AP or ICS, the broadcast trick grabs the MAC address, not the IP address.

I think you're thinking of the common bottom of the line ethernet switch. I'm thinking of a managed ethernet switch with VLAN (802.1Q) support.

There two isolation mechanisms working here. VLAN and "client isolation". Client isolation (or AP isolation as Linksys calls it) won't work with seperate boxes. It all has to be in the same box in order to isolate each port from each other.

For a VLAN, I can use an ordinary router and an ethernet switch that has VLAN features. Ports that need to access the internet are one VLAN. Ports that remain local (and therefore do not need to access the default gateway), are on the other VLAN. Wireless ports might be on a 3rd VLAN. Only one IP address required on the WAN. Any cross connections between individual IP's on seperate VLAN's can be done with routing on Layer 3.

Hmmm.... I've got this nagging feeling I've blown it here. Duz this sound right?

On Fri, 21 Jul 2006 05:49:28 GMT, Jeff Liebermann wrote in :

Ah, missed that, oversight on my part, plus you neglected to mention the need for a separate expen$ive switch. ;) The problems with VLAN, other than switch cost, are VLAN Hopping and the need for a VLAN-aware router. I personally think it's easier, safer, and more cost effective to use a hotspot wireless router, SonicWALL TZ-150 Wireless, Netgear Prosafe WG102, etc.

On Fri, 21 Jul 2006 15:14:32 GMT, John Navas wrote in :

Also OpenWrt firmware on compatible hardware, although that's essentially VLAN based.

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

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.

We know the MAC address of _everything_ that is connected to our net. Any unknown MAC or a known MAC vs IP mismatch observed causes that race between the guards and the NOC staff to see who can get to the drop first. On several of the subnets, we've taken it further, and alarm if a known MAC _or_ IP appears on the wrong switch port.

I'll agree with this.

Assumption - it's accepting your MAC, or you've spoofed his.

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.

Old guy

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

You won't necessarily be able to catch a sophisticated spoof that way. Better to rely on strong authentication.

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

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

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

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.

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

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 wrote in :

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 hath wroth:

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

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

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.]

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

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

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.

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.

As a guess, the nearest property edge is about 350 feet from one building, and the nearest building is closer to 500 feet. We're not down town ;-)

Ah, the joys of shared buildings. Yes, it's impressive to have an address like 485 Madison Avenue (NYC) or 1 Embarcadero Center (SFO), and several of our sales offices are in something vaguely close, but just about all the rest (including corporate headquarters) is out in the boonies. Land is a lot cheaper (to put it mildly), and you become a bigger fish in a smaller pond with the resultant power over the local town authorities.

It's as if they're selling closed solutions for the brane-ded. An IDS doesn't need to be some exotic box. Your little lap-doggy with a card that allows sniffing, is often enough to twig a problem.

This may depend on the box running the access point. It's not a sure thing. Example - the wireless net is a different IP range, and the access point is translating. Actually, I have another problem - I have over two dozen subnets on this facility, a few of them "air gapped" for various reasons. That means I don't have "instant access" to all internal traffic.

I did like this one:

] Not all rogue devices are created equal. When an early WIDS found a rogue ] device, wireless administrators would set out on a witch hunt, aiming to ] burn the policy violator at the stake. Inevitably though, the device ] would disappear along with the Sears service truck, or a walk-around ] would lead to the tenant a floor above.

The local Air Quality types won't issue burn permits, so the stake is out. Also, Sears isn't on our Approved Vendor list. But yeah, I know where they are coming from.

I haven't seen to many people set the MTUs down significantly - 1280 is the lowest outside of AX25 or RS232 that I've seen. The reason is simple, the excess to the fragment has to be sent as a separate tiny packet, OR you have to negotiate the MTU down (both of which are easy to identify).

It might make it harder on a fully automated tool, but something that uses the wireless packet as a trigger to snapshot the wire with the results presented to the eyeball is not going to be effected at all. Don't forget, we're not requiring a perfect match. All that is needed is enough to point at "that" box, and say "this looks suspicious". If I need more evidence before calling in an air-strike, I'll narrow the filter on the wired side to only look at packets to/from the suspect. If I see three 500 octet packets on wireless consistently with a 1500 octet packet on the wire... never mind that the average DNS query is only about 70 octets with something like 50 to 300 octet response from the name server... Hey RUBE!!! (and Guido) ;-)

Old guy

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!!!

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