Protected WLAN

[JD]

On 05/22/11 18:15, Tim wrote:
> On Sun, 2011-05-22 at 16:43 -0700, JD wrote:
>> Is there a tool or set of procedures that can identify
>> the source of an attack before it succeeds?
> It it only takes milliseconds to break in, what are you going to be able
> to do about it?  (If you're meaning for the device to tell YOU that it's
> under attack, for you to take some action to prevent it.)
>
> But seriously, if an attack on a wireless access point was to be made by
> trying out one password after another, that's an easy thing for software
> to detect and take some action against.  The trouble is that one
> possible reaction is to cause a denial of service to more than just the
> attacker.
>
> At least with wired networking, it's technically feasible that a really
> fancy router could cut off one port from traffic.  Unlike wireless which
> has one connection, shared between everybody.
>
> Protective measures such as filtering by IP or MAC have all the problems
> previously discussed in securing WLAN.  Plus the problem if the attacker
> has cloned your IP or MAC, such a method would shut you out as well.
>
> Likewise, it's technically feasible, and desirable, to detect port scans
> in progress (e.g. a remote IP is trying out connections to a variety of
> your ports).  Again the dilemma of what to do about it...  Block the IP?
> What if they'd cloned one of yours?  Or, they could simply try
> connecting from a different, unblocked, IP.
>
>> It seems to me that the net is really at the mercy of
>> the  wireless router/gateway. If it does not have/provide
>> a mechanism to send and alert to a daemon on a specific
>> machine about attempted break-ins (such as repeated
>> attempts of guessing the passphrase from some specific
>> IP address), we will never know of these attempts 'til
>> much later, or much too late.
> As I outlined at the start, there's not much point in ringing alarm
> bells about a break in.  It's too late, by then.  If you're going to
> take active measures against hacks, the wireless device has to do it
> itself.  Not make an alarm, but repel the attack.
Yes there is. The router could be programmed to ring
an alarm if there are say 3 or 4 repeated attempts at
associating with it, and at each attempt, the wrong
passphrase was used. Another thing that would be helpful
is for the router to temporarily blacklist the mac address
at the expense of blocking out an existing legitimate user
until the problem can be resolved. For our home, it is not
an unacceptable defense mechanism.
> I minimise the chance of (some) problems by setting my wireless access
> point so that configuration cannot be done over the wireless
> connections, a computer has to by physically plugged into it.  And the
> configuration password is different to the connection password.
>
> You can minimise other issues, by using an access point that doesn't
> allow one wireless connection to talk to another wireless connection, so
The router in use here has no such setting :(
Access point does have a setting to disable
admin access from the public network, which
is already employed.
> direct machine to machine probing isn't possible.  Though, if they can
> connect to your access point, they can still do whatever they're able
> to, to the wired side of the access point.
Well, you mean if they can succeed in breaking the wpa-psk/aes scheme?
That I think is something I am not going to worry about because it has not
been done yet by anyone (except the nsa of course).
>   And you may have the need
> for wireless devices to talk amongst themselves (peer to peer software,
> Samba, NFS, et cetera).
Yes.
> Personally, I wouldn't use wireless unless it was absolutely needed.
> That includes not using it *merely* because it's more convenient than
> wired.
Not an option as this house is not wired for ethernet
ports in every room.
> Not only are their security concerns, there's throughput issues, as
> well.  It's slower than wired ethernet.  Plus it's like using a hub
> versus a switch, everything has to take turns to communicate.  It's not
> possible for some terminals to simultaneously communicate between
> themselves, while some other terminals simultaneously communicate with
> other things.
Throughput is more of an issue for people with more
demanding requirements than myself.