web based authpf
Chuck Yerkes
>
> And they're all spoofable. try sniffing, finding another IP
> that is in use, and taking it over. There's a reason authpf is the way
> it is, in that it's actually realtively bozo-proof.
>
> When you combine it with redirecting unauthenticted web
> connections to a local server on the gateway that gives moron-level
> directions to how to authenticate, and the pieces you need if you
> don't have them, it's also pretty stupid proof. Hell, even people
> with all common sense surgically removed (A procedure called a PHd
> defense) can manage it here. Students have no problem at all.
Theo and Bob are right, you might want a stateful authentication
without IPSec.
ssh and authpf are great. If any of you are windows programmers,
write a little "click on me" utility that asks for a user/password,
makes an ssh connection and breaks it when closed. We shouldn't
need to give students/sr citizens an ssh window which would confuse
most people. Attach via ssh, send keep alives periodically.
Allowing tunnelling is a bonus.
> Of course, with the proliferation of morons runing
> wireless cafe services that are trivially subvertable, perhaps
> I won't need to care soon, The internet at large just won't
> expect wireless providers to care about the traffic coming
> from their networks, so I can just stop caring too...
Like university traffic is any different? This was an "issue"
in 1982 on my school's network.
Another way of doing it is by perhaps doling out 192.168.0.0 addresses
and limiting those hard. Then run IPSec and allowing the IPSec
given addresses through. It presumes some authentication has
occurred (a cert presented, shared secret, DNA verification, etc).
Its easier, certainly, in my neighborhood situation where people
have a smart access point that the ISP (the guy down the st) provides
and can control (eg, here's a box, stick the antenna on your roof
and plug your net in HERE).
Also, if the alternative is spoofable, it's often not worth closing.
If I spend X to prevent people from stealing $Y worth of bandwidth,
Y better be bigger than X.
If my Coffee Shack is pulling in $500/day by providing web access
and 2 people are swiping some of that, then it's often better money
to ignore. Shoplifters are undesirable, but the cost of stopping
all shoplifting is higher than the cost of dealing with it.
Businesses have different issues, but if someone can sniff a business's
wireless (breaking WEP is presumed) and get useful information from
that stream, they shouldn't have wireless. We always treated our
wireless traffic the same as traffic from the Internet - untrusted.
...
> >> I've been doing some poking around at the local Starbucks lately
> >> trying to figure out exactly how tmobile is doing the authentication
> >> on their wireless stuff. Soon as one comes in range, the local
> >> gateway (on 10.0.0.0/8 typically) will happily respond to DHCP
> >> requests with full info. However, outbound connections are limited
> >> solely to port 80, and those are redirected to an authentication
> >> server out on the public Internet. After authentication, all traffic
> >> outbound is allowed (not positive on this, as I haven't actually
> >> signed up for an account so I can test how this all works). Anyway,
> >> the authentication part is 100% browser based - works on any OS,
> >> including obsd, with any browser (reasonably certain it would work in
> >> lynx).
> >
> >If anyone finds a >dumb user< and secure way of doing this (that isn't
> >patented or something similarly stupid) please ount me in for a 'want to
> >know more'.
> >
> >I have a project starting up where I will be the lead on implementing a
> >subscription based wireless service. I love learning so little in so long a
> >time (802.11x I mean) ... :)
Paul Pruett
may be a substantial interest in an alternative for wireless authentication based
upon authpf.
So summarizing what I am gathering from the threads (please correct and
ammend if appropriate):
Recent inputs:
--------------
* past methods to login to website and then a cgi-bin changes ipf rules
are suspect.
* 802.1x is not secure enough to feel safe to change pf rules and is not
supported on many desktops like win98, winME etc...
* mac address nor IP address is not secure enough way to determine rules
* pfauth is good if implemented properly and client does ssh login and
stays logged in.
* not all computers have ssh client installed
* convenience of authenticating is necessary for novices at the expense
of inconveniece on the server side if necessary,
(yes I know convenience is indirectly proportional to security in most
cases, security=k/convenience)
* most computers have web browser that may run an applet to do ssh client.
* It's doable to have any port 80 or 443 go to a default webserver that
will kick off ssh applet. then hopefully person wanted to get through
firewall uses ssh login and authpf can then change pf.conf settings for
that user after ssh app authenticates.
* Hopefully the chosen java ssh applet can have the user do port 22
and authenticate, just kicking in authpf to change pf rules for that user
so long as the ssh client stays connected - correct?
* Version 1 of MindTerm is opensource w/o restrictions, but latest
versions are not, and MindTerm seems to do above step according to a
recent post to thread. Don't know of
alternative tested to work this way w/ authpf, but hope their is one or
community can take version1 and spawn of something w/o restrictions.
Possible inexpensive wireless testbed:
-------------------------------------
* computer w/ OpenBSD current (doesn't have to be powerful if no gui)
* a DWL-520 (not 520+) with prism2.5 chip supporting a host-based access
point mode which allows a card to act as a normal access point
* 1 or .5 watt 2.4 gig amplifier, LMR400 coax cable, some Ntype connectors
and type n adapters to male sma to screw onto PCI card, omni antenna and
brackets and misc antenna stuff.
* some thought on how to use IP addresses and break out subnets if needed
and gateways and nats and rdr (and pfauth does not rdr I read somewhere)
for the wireless client if using 10.0.0.0,
192.168.0.0 and other nonroute blocks...
* configuration of network and dhcpd for the wi interface
* configuration of pfauth and pf.conf appropriately (some labor hours here
for most of us ...)
* decide how pfauth will get user authentication, maybe as simple as add a
unix shell account, maybe better to get it elsewhere. pfauth uses sshd,
which uses various ways to authenticate, like keys or login/password so
one could give users a key to save to their computer where MindTerm would
look? or....
* A computer in the dmz w/ WebSite w/ Mindterm v1 that unauthenticated
users redirected to by default when coming through wi interface, and the default page w/
instructions.
* webpage to instruct users to open web browser to any website, then
follow instruction to fill out info in poppped up mindterm ssh java appplet
then leave it minimized and surf...
If someone has a adequate write up on doing the above, I would gladly post
to one or more of my websites and google it for us, else in my spare time
between 1am to 7am someweek(s) I'll try to ebay parts and try a test bed
and write up as soon as I can put out a few sysadmin fires and service
backorders. :)
-paul
On Tue, 25 Feb 2003, Mathias Wegner wrote:
> Networks, and ReefEdge. I'm sure it would be possible to put together an
> OpenBSD/authpf substitute, but there are an awful lot of small problems
> in anything but the most basic implementation. If you move it to a wired
> network, you do clear up a lot of the NAT, roaming, and IPsec issues.
>
> mathias
>
> --
>
> George W Bush:
> Compassionate Conservative turned Feckless Fascist
Steven Caesare
Dirk Rösler
current mechanisms seem appropriate. For example in a public-access
cafe scenario it will be the customer that is taking the impact from
any leaked information (his own). If the small print of the provider
says "communicate sensitive info at your own risk" he should have is
back covered.
Unauthorised (i.e. unpaid) use is the probably the provider's greatest
worry, but likely to be negligible, even given the weakness of MAC and
ARP based mechanisms. Probably not worth the effort, as described by
the shoplifting example by another poster.
If you have really sensitive information going over wireless, then you
shouldn't have completely clueless users at the first place, so either
clue them up or don't let them handle sensitive info. Then the usual
VPN principles apply.
What remains is that you may be providing "hack-spots". Efforts to get
accountability in case your users start hacking away, may be useless
when faced with arp-based attacks, and as described someone else can be
blamed instead. So user authentication (not machine authentication)
would help a great deal, and a pfauth-web solution would be a very good
technique. Question is whether the average provider cares... Also you
could limit even authenticated users to only say TCP ports 80, 443,
instead of all IP.
By the way, the requirement to start an ssh session prior to use isn't
that dissimilar to what you have to do using devices like BlueSocket,
Vernier etc. With those you usually have to go to some external URL
first, to get the redirection to the box' web interface for login. That
means e.g. that you cannot check your mail first. You must do the web
session first, then you can use other protocols.
A small ssh client which would pop up a user name / password box on
attempted network usage would be great!
Dirk
On Wednesday, Feb 26, 2003, at 01:45 Asia/Tokyo, Bob Beck wrote:
> People who rely on such devices have obviously never spoofed a
> mac address or poisoned an arp table in their life. MAC address locking
> does not work.