Re: Wireless Network in Public Places Options
From: Jeff Liebermann (jeffl_at_comix.santa-cruz.ca.us)
Date: 02/13/05
- Next message: Phil Agcaoili: "RE: Win2k or Win32 IPTABLES"
- Previous message: Steven L Umbach: "Re: Netlogon service problem"
- In reply to: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Next in thread: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Reply: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 12 Feb 2005 22:30:31 -0800
On Sat, 12 Feb 2005 11:01:53 -0900, floyd@barrow.com (Floyd L.
Davidson) wrote:
>>Using routeing to keep wireless clients seperated will only work if
>>the clients can be trusted.
>Not necessarily true.
Yeah, sorta maybe. If I can get the access point to bridge between
two client radios, none of the packets will go through the router.
Therefore tweaking the routing will do nothing to prevent this. I can
build a MAC layer that sends blindly sends everything to the router
port, and not repeat broadcasts or pass packets between wireless
devices, but that's not the way commodity wireless access points work.
If you just place an access point on the table, not connect the
ethernet port to anything, and setup two wireless laptops, it will
happily allow communications between the laptops. That's what the OP
was trying to avoid. Note that such laptop to laptop communication
could not be blocked by routing because (insert drum roll), there is
no router.
>>For example, I can easily setup a phony
>>DHCP server on a wireless laptop that will deliver a creative IP
>>address and gateway.
>
>The server on your wireless laptop can't provide an IP or a
>gateway route through the router. Hence, regardless of what it
>served up, the results would still be exactly the same... no
>route to another wireless client through the AP. Routing on the
>client makes no difference at all, nor does the IP address used.
>There simply is no wireless-to-wireless route.
There is no wireless to wireless "route" but there is a wireless to
wireless "bridge". Again, you're trying to solve a bridging problem
with route ting. You can do that, and it will work, if the client
computers are non-hostile. The nice thing about access points is that
they are Layer 3 independent. I have a wireless Novell IPX/SPX (plus
tcp/ip) bridge running between two medical offices. If I can get the
computers to talk on layer 2 (bridging), then there's nothing you can
do on Layer 3 to prevent that.
>And of course that *does* presume an AP/router which in fact
>routes wireless packets. As pointed out, that is the way it
>works with the WRT54G, which does not blindly send wireless
>packets to the ethernet switch.
I'm not sure how the WRT54G works. I can break out the 5th ethernet
port that goes to the wireless section and sniff the traffic.
However, it's much easier to just use a separate access point (WAP54G
or WAP11) and an ethernet router. I can sniff the traffic on the
cable in between, and see what it's getting. To the best of my
limited knowledge, the stock WRT54G *DOES* blindly send 802.3 ethernet
packets from the wireless port to the ethernet switch. If it didn't,
then broadcasts and arp request (no destination MAC address) would not
propagate from wireless to ethernet or ethernet to wireless. Since I
know they do or DHCP, ARP, SAP, ICMP, etc would not work.
However, if I assume that you're correct and the WRT54G does NOT
blindly dump packets into the ethernet switch, then what criteria does
it use? At this point, they are just 802.3 ethernet packets. No IP
layer involved or desired. What mechanism makes the decision as to
what to pass or block between wireless and ethernet? There's a MAC
address filter on the wireless side, but I've found that the filter
only applies to the wireless port.
>>I think route that IP address to the real
>>wireless access point and router going to the internet. Instant "man
>
>So just how do you route "to the real wireless access point and
>router"??? There is exactly one AP/router. It routes everything
>to the Internet...
>
>>in the middle" exploit. I can capture traffic going in both
>>directions and not even bother with removing the 802.11 encapsulation
>>required by wireless sniffing.
>
>Your description is not clear (it looks like a bit of editing
>went astray, so I'm guessing about what you meant, and may well
>be wrong). It sounds as if you mean you can set up another AP
>(not a wireless laptop), and operate it as a repeater to the
>real AP. That is a threat to a wireless network no matter what
>hardware is used.
Nope. It can be done with a single laptop and single radio. I really
didn't want to get into implementation. However, if you insist.
First, an ethernet *OR* wireless port can be made to act as a router.
It's easier to see using an ethernet port than with wireless. Also,
I've done this with a Freesco.org router and a Windoze 2000 based
router. The ethernet port can have two IP addresses. Linux (or
Windoze) will do IP Forwarding between the two addresses, on a single
port.
http://www.wown.com/j_helmig/w2kprout.htm
It's a rather gross and inefficient router as every packet appears on
the network twice (once for each IP address). However, it does work.
It's a bit more difficult building a one port router with a wireless
card. Some cards will allow two IP's on a single card, others will
not. Two radios in the laptop will certainly work.
So, one laptop radio connects normally to the hot spot wireless
router. The other radio is running an access point simulator, with
DHCP server, using the same SSID but on a different radio channel.
The unsuspecting client connects to the laptop instead of the hot
spot. The router software in the laptop forwards the packets to the
other radio, which forwards them to the hot spot wireless router.
Replace the router software on the laptop with a logger and sniffer
and you have a man in the middle exploit. Wanna throw some
advertising at the customers? No problem. Just sniff for URL's and
replace them with your advertising web pile. That should make the
customers thoroughly confused as they would first suspect spyware
instead of a man in the middle substitution exploit.
>So is passive sniffing.
Actually, you'll find passive sniffing to be somewhat of a challenge.
The problem is finding a location that can hear both the access point
and the client at the same time in order to capture both sides of the
traffic. That's fairly easy in a small cafe, but there are plenty of
other locations where it would be difficult to find a suitable
location.
>I agree that can be done.
If it can be done, it will be done.
>That is one reason the OP should 1)
>be considering physical security as well, and making efforts at
>limiting the signal coverage of his AP to the conference room;
Got it. Wifi absorbant wallpaper:
http://www.newscientist.com/article.ns?id=dn6240
>and 2) advise customers that they are responsible for encrypting
>their data sufficiently if industrial spying is a significant
>concern to them.
Groan...another warning label. Click here [ ] to approve the terms of
service, acceptable use policy, and general repudiation of
responsibility.
"Warning. Unencrypted WiFi may be dangerous to your security".
>(I would also point out that detection of the Man-in-the-Middle
>exploit would be only slightly above trivial... the provider
>can do sniffing too!)
Well, a simple traceroute will usually detect the extra hop. I once
hacked my Unix box to report a fake IP address in response to ICMP
ping and traceroute requests using hping and dnsspoof.
http://www.hping.org/manpage.html
http://olympus.het.brown.edu/cgi-bin/man2html?dnsspoof+8
>However, I'm unclear about exactly what you are referring to,
>given the above description fits one scenario and the below
>description is not at all the same. The one above, if I
>understood you correctly, requires adding hardware between the
>desired AP and the desired Client, while below you describe an
>example of poor administration.
>
>If by "wireless to wireless" above you also meant the same
>thing, it ain't gonna happen! The AP *won't* route from one
>wireless client to another in the example that I gave, and the
>route *is* in the data path.
Sigh. AP's don't route...they bridge. AP's don't have routers. AP's
can pass packets between wireless clients by bridging. No router or
routing required. AP's do not require a router to function. Think
bridging, not routing.
I think I clarified some of my points with examples. The man in the
middle attack can be done with a laptop and either one or two wireless
cards.
>>Last year, I got a call to see if I could do something about lousy
>>thruput at a WISP. They thought they had an RF interference problem.
>>After a day of useless RF sniffing, I started looking at the router
>>traffic. Nothing unusual or excessive. Eventually, I connected a hub
>>at where the access points came together and found LOTS of traffic
>>between access points or being repeated out of a single access point.
>>(The reason this wasn't done before is the access points were located
>>at 40ft on a tower). The system was being used as a repeater between
>>a bunch of gamers. All their traffic was wireless to wireless with
>>nothing going via the router to the internet. The problem was that
>>the access points on the tower had no provision for preventing their
>>use in this manner. They would merrily bridge between connected
>>clients.
>
>Which is to say, that is unrelated to the method that I
>described, which *does* have a provision to prevent use in that
>manner.
It's possible that your customized firmware WRT54G firmware does it
correctly. However, I'm suspicious. It's easy enough to test. All
you need are two wireless clients (or one wireless client and a LAN
wired client). Both should have IP addresses and no personal
firewalls running. Can you ping each other? If so, then you can see
each other, which means it's not working as you described. I just
tried it with my BEFW11S4 and my laptop can easily see the other
wireless clients on the LAN.
>>(The system WEP keys were cracked long ago). So, I just
>>blocked the MAC addresses involved, which slowed them down long enough
>>to fix the configuration. I dunno what was done to fix it as I only
>>did the RF part. They had a qualified and clueful service company
>>that only required that I explain 4 times why tweaking the router
>>isn't going to fix traffic problems that don't go through the router.
>
>Fine, but what I described is hardware that *does* run the
>wireless to wireless traffic through the router.
Nope. I can do the same thing with just an access point, which
doesn't even have a router attached. Again, think bridging (as in
layer 2) and forget about routing.
Incidentally, one of the really dumb ways to implement invisibility is
to deliver a netmask of 255.255.255.252 via DHCP. This doesn't always
work as some clients don't allow for the default route to be outside
the netmask. All current Windoze and Mac clients do, so it's not a
big problem. However, any clueful user can manually assign themselves
a larger netmask, making the other clients visible. Clever, but not
very secure.
>>>>Also, without any control, everyone would also get everyone else's
>>>>broadcasts.
>>>
>>>If they are indeed on the same network, that is exactly what is
>>>supposed to happen.
>
>What I said there is in error. That won't happen if there is no
>route to the client.
Ummmm... Not so. Broadcasts have no destination address. They go
almost everywhere. You can build a rule set or ACL that will block
broadcasts by type, but such fine control is not common on cheapo
routers. Since there is no destination address to route, there is no
way to use a layer 3 router to direct broadcasts as routing requires a
destination. All you can do is block them by type.
>>In a common shared network, broadcasts go to every machine on the
>>network.
>
>They go to every machine on the subnet, if there is a route.
>(In the example I gave, there is no route.)
Sorry. I missed the example. How do you control broadcasts by
routing? Without a destination address, there's no way to direct
broadcasts anywhere. That's why it had to be done on Layer 2 with
VLAN 802.1q.
>Well, I'm not guessing about the functionality that I described.
>I did guess that it had that capability, but before I spoke up I
>reconfigured a WRT54G as described and tried it.
Please pardon my suspicious nature.
How did you test?
Could the clients "see" each other?
Could you ping other clients? (No fair using personal firewalls).
-- Jeff Liebermann jeffl@comix.santa-cruz.ca.us 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 AE6KS 831-336-2558
- Next message: Phil Agcaoili: "RE: Win2k or Win32 IPTABLES"
- Previous message: Steven L Umbach: "Re: Netlogon service problem"
- In reply to: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Next in thread: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Reply: Floyd L. Davidson: "Re: Wireless Network in Public Places Options"
- Messages sorted by: [ date ] [ thread ]