diff --git a/tperimeter.txt b/tperimeter.txt index e483dc9..f391a6a 100644 --- a/tperimeter.txt +++ b/tperimeter.txt @@ -1,4 +1,4 @@ -.. 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 $ ===================================================== @@ -47,11 +47,11 @@ ``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. @@ -66,10 +66,10 @@ 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 @@ -85,7 +85,7 @@ 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 @@ -96,7 +96,7 @@ 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. @@ -168,7 +168,7 @@ 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:: @@ -178,9 +178,9 @@ -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 @@ -189,7 +189,7 @@ 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 @@ -260,7 +260,7 @@ 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 @@ -270,7 +270,7 @@ /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 @@ -309,7 +309,7 @@ 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 @@ -328,13 +328,13 @@ 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 @@ -423,9 +423,7 @@ ``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