Stuart Henderson wrote:
On 5/7/07, Darren Spruell <[EMAIL PROTECTED]> wrote:
On 5/7/07, Matthew R. Dempsky <[EMAIL PROTECTED]> wrote:
An attacker sets up a system with two wireless NICs: one associated to
my network and another configured as an access point pretending to be
an access point for my network. He runs a DHCP server on the AP
interface and NATs traffic to my network. (I can imagine a
sufficiently clever bridge setup that would be even harder to detect,
but I don't know for certain if it could work.)
It is no MITM on the *SSH* connection. Just that while the user is
correctly authenticated to authpf, other connections coming from the
same IP address also have access to resources.
"Configuration issues are tricky. The authenticating ssh(1) connection
may be secured, but if the network is not secured the user may expose in-
secure protocols to attackers on the same network, or enable other at-
tackers on the network to pretend to be the user by spoofing their IP ad-
dress."
It doesn't just happen with "attackers" but also anyone who happens to
be NATted to the same address.
It could warrant a mention in authpf(8) but then, where do you stop...
NAT? Multiuser UNIX systems? Infected windows boxes running proxies?
I'll give it a try for an additional paragraph...
"Access is granted to the IP address the user is connecting from,
but (e.g. as is the case where NAT or proxy servers are present,
legitimate or otherwise) it can not be guaranteed that other users
cannot originate a connection with that same IP address and so
gain access to resources protected by authpf(8)."
Well, it's a start, but... yeuch.
this reinforces what we already know to be true: if you're serious about
security over wifi you should be using ipsec to guarantee authenticity
and confidentiality.
it would be nice to have some of this framework in authpf but it seems
redundant considering that it's already available. ease of use is always
an issue...
cheers,
jake
