FAQ, Frequently Asked Questions
- Why is the access server called oasis?
- What operating systems does Oasis run on?
- How do I configure Oasis to authenticate against a Kerberos KDC?
- How do I add another upstream provider?
- I'm a user. What is required to connect?
- I'm a provider. What is required to connect?
- Is Oasis open source?
- How is access verification done?
- How long can a user be logged in?
- Why don't you use PPPoE or <insert technology here>?
- How secure is this?
- I have a DHCP server, access server and firewall colocated in the same machine, why doesn't it work?
- Do the users need to enter the address to the login page each time?
- How can I create a special class of users with limited access?
Why is the access server called oasis?
Oasis ("a green area in an arid region") in swedish is "oas", which in turn is an acronym for Open Access Server.
What operating systems does Oasis run on?
Oasis should run on Linux and FreeBSD (tested with Debian GNU/Linux 2.2/3.0, RedHat 7.2, FreeBSD 4.4/4.5) if openssl, libpcap, libnet and libpthreads are installed. The sample firewall script installed uses iptables so it needs to be rewritten for FreeBSD to support ipfw. If you do, please contribute an alternative script that can be included in the distribution.
How do I configure Oasis to authenticate against a Kerberos KDC?
Assuming your KDC is setup appropriately (check that you can get a ticket with kauth on the machine running oasis), you have to install a Kerberos PAM module (available on the download page). Then configure the PAM service to use the Kerberos PAM:
auth required pam_krb4.so MY.REALM
This line should be put in /etc/pam.d/oasis, or whatever service you specified with pam-service in oasis.conf.
How do I add another upstream provider?
If you have installed the required upstream services (access server, DHCP server and gateway), then you only have to edit the provider configuration in the MAC database. Enter
psql -Umacbind macbind
to connect to the PostgreSQL database. Type
SELECT * FROM T_provider;
to list all the configured providers. Add the provider by entering
INSERT INTO T_provider (provider_name,
provider_dhcp,
provider_auth_url,
provider_net,
provider_netmask)
VALUES ('Name of Provider',
'10.0.0.3',
'https://auth.provider.com/',
'10.0.0.0',
'255.255.255.0');
Substitute the VALUES that corresponds to the new provider. To use that provider, open the registration page and choose it in the list. Restart your DHCP client to obtain an IP address from the new provider.
I'm a user. What is required to connect?
This is what you need:
- Obviously you need a network card (of some sort: vanilla ethernet 10/100 Mbps or an IEEE 802.11b/a depending on the network infrastructure).
- A DHCP client. This is probably part of your operating system. In windows, select "Obtain an IP address automatically" in the network settings in the control panel.
- A web browser (that supports SSL). Internet Explorer, Netscape, Mozilla, Opera or Lynx-ssl will do fine.
Connect to the access network (if you use 802.11b, make sure you set the ESSID and possible encryption keys correctly). You will get an IP address automatically via DHCP. Point your web browser to the login page (http://auth) and follow the instructions.
I'm a provider. What is required to connect?
You need a gateway directly connected to the access backbone. The gateway must have a firewall that can be remotely controlled by the access server and be able to filter on IP and MAC address.
You also need a machine for running the access server, also located directly on the access backbone (at least for the implementation available from us). You can choose to use any access server you like. The Oasis access server is however ready to use, and can be configured to re-use any authentication infrastructure you are currently using (eg, RADIUS or Kerberos).
You need a DHCP server to configure the clients. Clients requests will be forwarded by the relay agent in the access backbone to your DHCP server, which must be located outside the access backbone in order not to interfere with the relay agent. The common relay agent needs an IP address from your address pool and your firewall must allow DHCP traffic from the relay agent to your DHCP server.
Is Oasis open source?
Yes, Oasis is licensed under the terms of the BSD license.
How is access verification done?
Access is verified in the firewall of the providers gateway by filtering on IP and MAC address.
How long can a user be logged in?
There is currently no time limit for how long a user can be logged in. Users are logged out by the system when they disconnect from the network. Disconnection detection is done either by actively probing the user (pinging) or passively by listening on the traffic in the gateway, or a combination thereof.
Why don't you use PPPoE or <insert technology here>?
One of the constraints we set up when designing the system was that users should not need to install special software. Using PPPoE would require client software, which also must be ported/supported for all available platforms. The minimal requirements (DHCP client, SSL web browser) are met in all(?) operating systems.
Using web based login is user friendly, and also the easiest/quickest to implement/maintain.
How secure is this?
We believe that this system is secure enough. It is not bullet proof, a user could spoof IP and MAC address and thus get unauthorized access. However, no access to critical data is gained this way.
Users concerned about security should use a VPN or other application level encryption software.
I have a DHCP server, access server and firewall colocated in the same machine, why doesn't it work?
You can't have the DHCP server listening for requests directly from the users. This is because the relay agent is used to distribute the request to the right server, and in this case the server would answer to the user anyway. The Right Way to do it is to have the DHCP server in another machine located in the upstream network.
Blocking requests from the users by filtering out any IP except for the relay agent in the firewall doesn't work either. This is because the DHCP server (at least in the case of ISC DHCP) puts the network card in promiscuous mode in order to get the broadcasted messages. This bypasses the firewall.
An alternative is to have the DHCP server listen on a non-standard port like 1067 and have the relay agent forward requests to this port. This, however, probably requires patching both the server and the relay. The ISC DHCP server can be made to listen and send on a non-standard port with the -p argument, but then the relay agent needs to listen on this port as well as the standard port 67.
Do the users need to enter the address to the login page each time?
No, you can use forced redirection in the firewall to redirect unauthenticated users to the login page when they try to access something outside. This way users need no instructions for how to access the network, they only have to follow the instructions on the login web page (well, assuming the users only browse the web).
Using iptables on Linux you can use the REDIRECT target to redirect traffic on port 80 (http) and 443 (https) to a local port where a local webserver listens. If Oasis and the firewall is colocated in the same machine this is all that is required. If they are not, run a light webserver or custom application on the firewall that only issues an http redirect to the client.
Take a look at the default firewall script (uses iptables).
How can I create a special class of users with limited access?
Create a new domain in the oasis configuration file and change the firewall script for that domain. The new firewall script can control the same firewall, but with different rules, for example only allowing access to web servers.
You will also need another PAM configuration file for authenticating only a subset of the users. The PAM module pam_listfile can be used for this:
auth required pam_listfile.so onerr=fail sense=allow item=user file=/etc/myrealm-acl auth required pam_krb4.so MY.REALM
This will first require that the user name exists in /etc/myrealm-acl, then check the user in the KDC for MY.REALM.