Re: Wireless ISP



On Wed, 25 Jan 2006 17:36:47 +0100
Erik Norgaard <norgaard@xxxxxxxxxxxx> wrote:

> FootballCALL wrote:
> > Hi,
> >
> > I am based in the UK and wish to set up a wireless community
> > broadband service to residents and businesses in my community.
> > From my access point, I would like other users to 'share' my
> > connection through wireless technology and therefore they will
> > pay a nominal amount for their internet access.
> >
> > I therefore require a home page/login page so only registered
> > users can use the connection, and also need to manage bandwidth
> > of these users.
> >
> > Is this something you can help with?
>
> This depends on what kind of access you want to offer and the need
> for security:
>
> A web only? Then set up a proxy with authentication. Create a
> website for initial registration and maybe allow any connection to
> a service like paypal to receive payments.
>
> If you want to offer more than web-only, then it becomes
> complicated. You can require registered users to authenticate using
> putty - each user is given an account with authpf as shell.
>
> Depending on setup, this may not limit the number of connections to
> one, so you risk that people share their credentials.
>
> I have created a simple setup that relies on mac addresses. IP is
> assigned statically and I maintain a static arp table. All other
> web-address is directed to a default page that shows they don't
> have access.
>
> The advantage is that users are not bothered with authentication,
> the disadvantage is that mac addresses can be spoofed.
>
> The bad thing is that to make new users aware of the AP it is open
> and unencrypted, so you can get a lease and reach the access-denied
> page. But, this also means that any one can start sniffing for
> valid mac/ip address pair and spoof their way to access.

I though nearly every aviable radio all ready did this as well as
frequency hoping?

> For my single AP with only a few users, I think I should be able to
> catch abuses and if so implement stronger checks.
>
> For security, the proper way would be to issue encryption keys and
> require registered users to open a VPN to the gateway. This will:
>
> - force authentication
> - encrypt traffic
> - prevent spoofing of traffic
> - allow the AP to announce itself and be open
>
> and likely some more goodies. The disadvantage is the complex
> setup, in particular for the novice users, and when people get on
> other networks they might have to reconfigure their computer.
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.security.unix)
  • understanding chkrootkit: sshd section
    ... Rhosts Authentication disabled, originating port will not be trusted. ... Secure connection to %.100s on port %hu refused%.100s. ... Warning: Remote host refused compression. ... Received RSA challenge from server. ...
    (comp.os.linux.security)
  • (fwd) FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn (fwd)
    ... susceptible to attack than other unencrypted sessions. ... > incoming connection is being established, ... > All versions of FreeBSD 3.x and 4.x prior to the correction date ... > requiring other authentication of the originator are vulnerable to ...
    (FreeBSD-Security)
  • Re: understanding chkrootkit: sshd section
    ... Connection will not be encrypted. ... > Rhosts Authentication disabled, originating port will not be trusted. ... > Could not request local forwarding. ... Remote host failed or refused to allocate a pseudo tty. ...
    (comp.os.linux.security)
  • Re: understanding chkrootkit: sshd section
    ... Connection will not be encrypted. ... > Rhosts Authentication disabled, originating port will not be trusted. ... > Could not request local forwarding. ... Remote host failed or refused to allocate a pseudo tty. ...
    (comp.security.unix)