Fork: 0
tundra / tperimeter
Browse code
Minor typo changes. Removed references to a FreeBSD port.
master
1 parent 4b53076 commit 0b0f90cd2a006e02abda6f811ac82bfb11700412
@tundra tundra authored on 25 Sep 2006
Patch
Unified Split
Showing 1 changed file
View
38
■■■■■
 tperimeter.txt
.. footer:: $Id: tperimeter.txt,v 1.112 2006/09/25 18:56:13 tundra Exp $
.. footer:: $Id: tperimeter.txt,v 1.113 2006/09/25 19:38:04 tundra Exp $
 
 
=====================================================
``tperimeter`` - A Dynamic TCP Wrapper Control System
 
``tperimeter`` has two major components:
 
1) A *reqestor subsystem* that presents the user a web page to
request a "hole" be opened in the tcp wrappers for a specific
request a "hole" be opened in the TCP wrappers for a specific
service from a particular IP address. This request is then
enqueued on disk for subsequent processing.
 
2) A *tcp wrapper rewrite* mechanism that periodically (under ``cron``
2) A *TCP wrapper rewrite* mechanism that periodically (under ``cron``
control) rebuilds the ``/etc/hosts.allow`` file to reflect
any pending user requests queued by the requestor subsystem.
 
The workflow is fairly simple:
 
3) The ``cron`` job then *deletes* the request from the
``tperimeter`` queue. This means that the next time
``hosts.allow`` is rebuilt by the ``cron`` job, the "hole"
``tperimeter`` opened in the tcp wrappers will be *removed*.
``tperimeter`` opened in the TCP wrappers will be *removed*.
This ensures that someone doesn't open a hole in the system that
then stays there permanently. This works fine in practice,
because the tcp wrapper security model operates only at the time
because the TCP wrapper security model operates only at the time
of the initial connection request. The ``tperimeter`` semantics
were designed to open a hole only long enough to allow the user
to make the initial connection - that will stay in place even
after the wrappers are closed back up to their default state.
address they want opened. ``tperimeter.py`` is a CGI script that
parses the user's input and actually places it on the disk queue for
subsequent processing.
 
``rebuild-hosts.allow.sh`` is the tcp wrapper rewrite mechanism.
``rebuild-hosts.allow.sh`` is the TCP wrapper rewrite mechanism.
It is intended to be run periodically as a root ``cron`` job. Remember
that the "hole" ``tperimeter`` opens in your wrappers stays in
place until the *next time* the ``cron`` job runs. We thus recommend
running this script every 5 to 10 minutes to keep the window of
The queue where ``tperimeter`` requests are initially deposited and
subsequently processed is transparent to the user and requires no
administration by the system administrator. The queue is created by
the web interface when a request is made. It is then subsequently
processed by the tcp wrapper rewrite mechanism and then deleted as
processed by the TCP wrapper rewrite mechanism and then deleted as
described above.
 
Each request ``tperimeter`` receives is logged in the system log.
It is in the form::
script directly from a URL and bypassing your website security::
 
ln -s /www/RemoteAccess/.htaccess .htaccess
 
Next, you need to install the tcp wrapper rewrite subsystem:
Next, you need to install the TCP wrapper rewrite subsystem:
 
1) Create the directory::
 
mkdir -p /usr/local/etc/tperimeter
2) Copy the ``rebuild-hosts.allow.sh`` file to this directory.
 
 
 
Now, you have to create the entries that describe your "default" tcp
Now, you have to create the entries that describe your "default" TCP
wrapper configuration. ``tperimeter`` has to know how to build your
"standard" tcp wrapper file - i.e., The ``hosts.allow`` entries you
"standard" TCP wrapper file - i.e., The ``hosts.allow`` entries you
*always* want in place regardless whether or not there is pending
requests for temporary access via the web interface. That's because
``rebuild-hosts.allow.sh`` runs periodically under ``cron`` control and
rebuilds the *entire* ``hosts.allow`` file.
 
To make this simple, the list of things you always want in your
``hosts.allow`` file is represented by a directory tree with
zero-length files in it. ``tperimeter`` uses the *names* of these
directories and files to build the default tcp wrapper file. This is
directories and files to build the default TCP wrapper file. This is
a fairly standard Unix idiom - using the file namespace to represent
some larger behaviorial semantic. This file tree is also found in
``/usr/local/etc/tperimeter``. You'll find an example of what goes
where in the ``tperimeter-sample`` directory included in this
add or deny access for a particular host, just go to the service
directory in question and ``touch`` a file by that name. To remove
access or denial, go to the directory and delete the file by that
name. Thereafter, when ``rebuild-hosts.allow.sh`` runs again, it will
build a new tcp wrapper control file with your new settings.
build a new TCP wrapper control file with your new settings.
 
You can see what your changes will look like by running
``rebuild-hosts.allow.sh`` manually. By default, it emits output
to ``stdout``. You can even rebuild the ``hosts.allow`` file yourself
 
/usr/local/etc/tperimeter/rebuild-hosts.allow.sh >/etc/hosts.allow
 
 
Finally, you need to create a ``cron`` job that runs the tcp wrapper
Finally, you need to create a ``cron`` job that runs the TCP wrapper
rebuilding process regularly::
 
# Update /etc/hosts.allow to accommodate any tperimeter requests
0,10,20,30,40,50 * * * * /usr/local/etc/tperimeter/rebuild-hosts.allow.sh >/etc/hosts.allow
2) Similarly, there is no locking done when the ``hosts.allow`` file
is rewritten. The script that produces the new version of this
file simply overwrites it. There is the possibility that, at the
moment that file is being created, someone will attempt to access
your system when there are no tcp wrapper rules in effect. In
your system when there are no TCP wrapper rules in effect. In
designing this system, it was felt that this exposure was quite
low. If this turns out not to be the case (remember, this is
EXPERIMENTAL software), then the ``hosts.allow`` rewrite
mechanism will have to be rewritten to make sure that there is
been granted by ``tperimeter``. For this reason, the wrapper
rewrite script places any ``tperimeter`` access at the beginning
of the ``hosts.allow`` file before your default configuration
statements. This should be benign, but it does have the effect
of circumventing your strict tcp wrapper rules and you should
of circumventing your strict TCP wrapper rules and you should
be aware of this. If you don't like this semantic, you can
modify the ``rebuild-hosts.allow.sh`` file to suit your
preferences.
 
4) The ``tperimeter.py`` file is written to require full IP
quads when requesting access. For example, although tcp
quads when requesting access. For example, although TCP
wrappers allow entries like ``64.23.`` to specify a range
of addresses, you *cannot* enter such an IP specification via
the ``tperimeter`` web interface. You also cannot specify
the host from which you desire access by using its name, only
-----------------------
 
 
``tperimeter`` is Copyright(c) 2006 TundraWare Inc. For terms of use,
see the ``tperimeter-license.txt`` file in the program distribution. If you
install twander on a FreeBSD system using the 'ports' mechanism, you will
also find this file in /usr/local/share/doc/twander.
see the ``tperimeter-license.txt`` file in the program distribution.
 
 
AUTHOR
------