Photo credit
OOBA controls access to or through the computer on which it runs. Each client computer (yours) has an Internet Protocol (IP) address, and OOBA causes the host computer to ignore all traffic from every client (except OOBA web service itself) unless the IP address has been authorized. To authorize your client's IP address, you need to use a web browser to connect to the OOBA service, and present it with a valid credential: either a loginID and password, or a X.509 certificate signed by an acceptable authority. That being done, the host computer will accept packets from the authorized IP address.
Typically password and X.509 authentication are done on different ports so users without certificates aren't asked to present one. If you get onto the X.509 port by accident, or if your certificate is defective, e.g. expired, just decline to send one (click on cancel in the browser's dialog box), and give your loginID and password instead.
You can adjust how long the authorization will last, up to a maximum set by the system administrator. If you set a short life, like 24 hours, you will often need to re-authorize your client. If you set a long life, you may forget that OOBA authorization is necessary and how to do it. Unfortunately, when the authorization runs out the host computer will cut off your access with no error messages.
If you use your authorization, i.e. make connections to the host computer,
the authorization will automatically be renewed for the lifetime you set.
Similarly you can reauthorize an authorized client, which will renew the
authorization. On the other hand, home computers do not get a static IP
address unless you pay extra, and some providers insist on changing the
address daily. When your IP address changes you will need to authorize
the new address. You can mark the checkbox remove old authorizations
to pre-expire the authorization(s) you are no longer using.
Hostile viruses, worms, zombie bots and human attackers are pervasive and rampant on the Internet. If the host machine is up to date on security patches it can resist their malicious sendings, but some categories of attacks use significant system resources, in particular when the attacker tries to log in by guessing weak passwords. The system should require users to have passwords that are hard to guess, but even so, the load caused by unsuccessful password guessing attacks interferes with productive system operations.
OOBA is just about the only defense that can resist password guessing attacks, by simply dropping all packets from unauthorized clients. In some guessing attacks the client makes many connections in a short period, and this behavior can be recognized, but the more sophisticated attacks are done with stealth and will penetrate that kind of defense. If OOBA becomes popular the attackers could try a guessing attack against OOBA itself, but OOBA uses much less resources than a full (failed) login.
OOBA is also a component of defense in depth: if the attacker has a new exploit to which the host would be vulnerable, he cannot deploy it if OOBA is dropping packets, with no need for special work to resist the specific attack. On the other hand, OOBA is not a universal defense: we have to assume that an authorized home machine or rented equipment in an Internet cafe is full of viruses, which each host must be prepared to resist by other means.
Continuing on the justification for OOBA: at the author's site there are several home directory servers and over a hundred Linux workstations and compute cluster nodes, plus many Windows boxes. The attackers connect to the Secure Shell port (22) on all responding hosts on our subnets, and attempt to guess passwords, usually using known loginIDs from spam lists, or at least using speculative loginIDs many of which exist. To do a SSH login the workstation needs to NFS mount the user's home directory. The incessant pounding on the home directory servers interferes with backups, nightly administrative scripts, and general service to the users.
The OOBA authorization page has a few extra features for people with
administrator rights. First, the administrator (once authorized) can alter the
IP address, so as to authorize a client other than his own. It is also
possible to authorize an entire subnet by adjusting the CIDR bit count. The
loginID of the requesting
user can also be altered. Finally, the
show all
checkbox shows all authorizations; normally only those for the
named user are shown.
A trick for administrators: if you ever need to (temporarily) deactivate OOBA, just authorize the subnet 0.0.0.0/0 (the entire Internet).
Authentication is propagated from one screen to the next by an encrypted cookie in the form, which generally has a short timeout like five minutes (unless administratively adjusted). If your cookie expires and you need to give your password again, remember to change back to your own loginID. An X.509 certificate is more convenient for administrators.
There are three aspects to configuring OOBA: the configuration file, the OOBA web form, and textual substitution.
The format of the configuration files resembles Bourne shell variable
settings. Comments begin with # and extend to the end of the line. Empty
lines and lines containing only comments are ignored. Effective lines have
the form key=value
, optionally with double quotes around the value.
Trailing whitespace and comments are removed from the value, but internal
whitespace is kept. A null value looks like just key=
.
OOBA reads configuration data from these sources; if a parameter appears multiple times the last one is used.
These are the parameters; the values shown are the actual defaults:
Hardwired name of config file.
For the web page title and messages.
Space separated list of loginIDs of users who get administrator rights. It is probably not a good idea to actually use the root user as the administrator.
Anyone in this group has administrator rights. Only one group can be specified.
The database, web documents, etc. are here. Any relative paths are
relative to this directory. A relative path must have at least one slash
to be recognized; use ./filename
if necessary.
The daemon writes its PID here.
Name of service for SASL and PAM authentication. To use PLAIN authentication (loginID and password) with SASL, you need /usr/lib/sasl2/$service.conf which in the normal case contains just:
pwcheck_method: saslauthd
mech_list: plain
And of course saslauthd has to be running. In the likely case that it has the "-a pam" option, you also need /etc/pam.d/$service which contains PAM sections for auth and account. (password and session are not used.) Avoid expensive operations like checking if the home directory exists.
Space separated list of webserver ports. Security by obscurity: pick obscure and unique ports. Suffix codes:
Integrated Engineering Softwarehttp://www.integratedsoft.com/. Electromagnetic calculations, e.g. motors, electron tubes. Very much alive, but I don't know if the protocol is still used.
Marcam License Managementappears to be used with the MAPICS database (?) on the IBM AS/400. It was big in 1996-1997 but has almost no web notice since; last e-mail in 2004. But may not yet be bankrupt; it's mentioned in a 2008 Gartner report. No web site.
This host's X.509 cert for SSL.
Unencrypted private key for that cert.
This file is a bundle of concatenated authority certificates. Client certs signed by any of these are honored for admission. Also see certauthdir.
This directory has links to authority certificates named from their
subject hashcodes. Client certs signed by any of these are honored for
admission. You should specify just one of certauth or certauthdir. Here's
an example of how to create the hashcode -- append .0
in the usual
case that there are no duplicates:
openssl x509 -in ucla-math.crt -noout -subject_hash
# Suppose it prints e4a7f639
ln -s ucla-math.crt e4a7f639.0
1 to check if the client cert is revoked; 0 to omit.
Default life of an authorization in hours.
Maximum life of an authorization in hours
1 means that authorizations are automatically extended if the host sends traffic; 0 to not renew.
How long to wait for the file lock (secs).
Minimum time between cleaner runs (secs).
Maximum time between cleaner runs (secs). The cleaner normally runs at the moment the next authorization expires, unless the needed delay is outside these bounds.
File that can be read to get random entropy for cryptography. It's important for OOBA to continue to function if abused; specifically, if entropy is depleted it's better for OOBA to fake it than to block, and so /dev/urandom is recommended in preference to /dev/random.
Name of cryptographic algorithm; consult the documentation for Perl's Mcrypt and/or the general man page for mcrypt. Omit the package prefix (Mcrypt::).
Cryptographic mode from Mcrypt; CFB is best for OOBA; STREAM also is OK.
Name of hash function (with package prefix). Consult the documentation for Perl's Digest package.
Cookie expires after this many seconds, after which the client must authenticate again.
Saslauthd socket with basename .../mux
Command to grant access to a host. The string %I is replaced by the authorized IP address (with CIDR bits, typically /32). An actual iptables command is normally used, but a wrapper script can also be written; this would probably be necessary if the actual router were a Cisco box.
Similar to cmdgrant, but to revoke access.
Command to make a list of rules that accept traffic from authorized clients. See listorder.
Two integers space separated, identifying the columns (zero origin) in the output of cmdlist which give, in this order, the IP address and the number of packets or bytes handled by the rule (to know when to renew an authorization). The IP address must match exactly the address given to cmdgrant, including CIDR bits. Report rows in which either field has alphabetic characters (header rows) are ignored.
Syslog facility for all log output. Give a null string to not use syslog.
Syslog level for grant and revoke messages, null string to omit them, STDERR to write to stderr.
For debug messages, a null value omits them, STDERR puts them on
stderr, and anything else (typically debug
) is a syslog level at
which they are logged.
The OOBA web pages are found in $oobadir/htdocs. Relative links on these pages are relative to the referring page, as on any web site, and will be sent out by the OOBA server. Absolute links to another host, or to the OOBA server host on a different port, will be sought by the client's browser from the other web server, in the normal way. Normal files are simply sent out as an ordinary webserver would do. For a directory the program sends out index.shtml or index.html, whichever exists, or else kludges up a directory listing (not recommended).
You are free to provide your own content in the OOBA web pages, e.g. to translate them to your own language, add a local policy statement, or add links to your helpdesk pages. The provided pages are very simple, and you may feel the need to add pages for various purposes. However, extensive discussions of policy and implementation are best hosted on your regular webserver.
Web pages with the .shtml extension are special: the OOBA server looks for and obeys a web form that may have been sent with the request, and it does extensive textual substitutions on the page content that is sent back to the client. First, it does Server Side Includes, of which the following formats are recognized (Apache can do more variants):
The filename must be relative (to the includig file's containing directory). Included files may include other files.
<!--#include file="relativepath" -->
After inclusion, the content is scanned for percent escapes; for example,
%c
is replaced by the company
configuration parameter wherever
occurring. If a particular value is unavailable, a null string is substituted.
Here are the available substitutions:
Companyparameter (company name)
lifetimemaxparameter)
DISABLED, except if the client has administrator rights, %a expands to a null string
authentication from X.509 certificate
%T and %t deliver one table row (<tr> object) per authorization or
rule, or if there are none, one row saying (None)
. The page author
needs to provide <table>, <col>, column labels, etc.
To get the client authorized, the client's web browser must send in a form with a request for a .shtml page. The provided index.shtml page shows how to make up this form. The fields that the OOBA server looks for are:
The encrypted cookie telling which user is authenticated. This should be in a hidden field because it's ugly (not because anything bad happens if the user sees it).
The user's loginID shown in the form. Administrators can specify a loginID other than their own.
The authenticated user's password for PLAIN authentication. Leave blank for a X.509 certificate or if the cookie is valid.
IP address (with subnet bits) to be authorized, e.g. 192.168.0.100/32. The administrator can authorize subnets, or hosts other than his own. The netbits will be appended if missing.
How long to authorize access, in decimal hours, e.g. 2.4 or 24; 0 means to expire the authorization immediately.
True (1) to authorize the {ipaddr} host; this should be marked by default.
True (1) to remove (other) authorizations for {user}.
True (1) to show all authorizations, not just {user}'s. Use %a to disable this except for administrators (the program also checks).