diff --git a/tperimeter.txt b/tperimeter.txt index f0dea44..c8ecde0 100644 --- a/tperimeter.txt +++ b/tperimeter.txt @@ -1,4 +1,4 @@ -.. footer:: $Id: tperimeter.txt,v 1.105 2006/09/25 07:22:30 tundra Exp $ +.. footer:: $Id: tperimeter.txt,v 1.106 2006/09/25 07:55:35 tundra Exp $ ===================================================== @@ -51,7 +51,7 @@ 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. @@ -60,12 +60,12 @@ 1) The user logs into the ``tperimeter`` web interface and specifies from what IP address and which service they want to access your system. - 2) A cron job periodically runs to process any such pending requests by + 2) A ``cron`` job periodically runs to process any such pending requests by dynamically rewriting the ``hosts.allow`` file. - 3) The cron job then *deletes* the request from the ``tperimeter`` + 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 + by the``cron``job, the "hole" ``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 @@ -85,9 +85,9 @@ subsequent processing. ``rebuild-hosts.allow.sh`` is the tcp wrapper rewrite mechanism. -It is intended to be run periodically as a root cron job. Remember +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 +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 exposure small. @@ -98,22 +98,6 @@ processed by the tcp wrapper rewrite mechanism and then *deleted* as described above. -However, there is a second queue that is of considerable importance to -the systems administrator. ``tperimeter`` has to know how to build -your "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 a fairly standard -Unix idiom - using the file namespace to represent some larger -behaviorial semantic. Here's how it works: - - - HOW TO INSTALL ``tperimeter`` ----------------------------- @@ -188,16 +172,102 @@ -Finally, you need to create a ``cron`` job that runs the tcp -wrapper rebuilding process regularly:: +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 +*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 +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 +distribution that may be helpful as you study the following material. + + 1) The ``prologue`` and ``epilogue`` files are simply copied + respectively to the beginning and end of your ``hosts.allow`` + file. You can put any custom wrapper statements in these + files as needed. + + 2) The ``allow`` and ``deny`` directories contain entries + for specific services you wish to allow or deny. You + create a directory under these for each *service* you want + to control. Within that "service directory" you create + (using ``touch``) one or more zero-length *files* whose *name* + is the IP address or DNS name of the host you are allowing/denying. + + Say you want to allow ``ssh`` access from 64.2.3.1 and anyone in + 10.0.1.x, and deny ``ftp`` access from everyone. Then the + directory/file layout would look like this:: + + /usr/local/etc/tperimeter/ + + allow/ + sshd/ + 10.0.1. <--- This is a file + 64.2.3.1 <--- This is a file + deny/ + ftpd/ + ALL <--- This is a file + + + When ``hosts.allow`` get's rebuilt, this would result in two + wrapper statements:: + + ftpd: ALL :DENY + sshd: 10.0.1. 64.2.3.1 :ALLOW + + +When ``rebuild-hosts.allow.sh`` runs under ``cron`` control it will +scan this directory structure. First, it will emit any pending +``tperimeter`` access requests. Then it will emit your ``prologue``. +Then it will process your ``deny`` entries in the format just +described. Then it will do the same for your ``allow`` entries. +Finally, it will emit your ``epilogue``. You should keep several +things in mind when laying out your individual allow/deny entries: + + 1) All ``deny`` entries are processed *before* your ``allow`` + entries. This means the ``deny`` statements will appear + before any ``allow`` entries in your ``hosts.allow`` file. + + 2) The entries in a given service directory are processed in + alphanumeric order and will appear in your ``hosts.allow`` + in that same order. + + 3) Take care to name your service directories properly. They + must be named in the form tcp wrappers expect them - i.e. With + the naming convention used in ``/etc/inetd.conf``. ``ssh`` + access is in a directory named ``sshd``, ``ftp`` in ``ftpd`` + and so on. + +Once you get the hang of this, it is really simple to administer. To +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. + +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 +if you don't want to wait for ``cron`` to do it:: + + /usr/local/etc/tperimeter/rebuild-hosts.allow.sh >/etc/hosts.allow + + +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 - - - CUSTOMIZING ``tperimeter`` --------------------------