diff --git a/tperimeter.txt b/tperimeter.txt index 89cb94c..a1fe264 100644 --- a/tperimeter.txt +++ b/tperimeter.txt @@ -1,4 +1,4 @@ -.. footer:: $Id: tperimeter.txt,v 1.110 2006/09/25 08:23:23 tundra Exp $ +.. footer:: $Id: tperimeter.txt,v 1.111 2006/09/25 18:50:18 tundra Exp $ ===================================================== @@ -58,25 +58,26 @@ The workflow is fairly simple: 1) The user logs into the ``tperimeter`` web interface and specifies - from what IP address and which service they want to access your system. + from what IP address and to which service they want access. 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`` - 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*. 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 of the initial connection request. - The ``tperimeter`` sematics 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. So, for example, you can open - access with ``tperimeter`` to gain access for, say, ``ssh``. - Once you've made the connecton, it remains connected even after - ``hosts.allow`` is rebuilt to its default closed state. + 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*. + 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 + 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. + For example, you can open access with ``tperimeter`` to gain + access for, say, ``ssh``. Once you've made the connecton, it + remains connected even after ``hosts.allow`` is rebuilt to its + default closed state. The requestor subsystem consists of two parts. ``tperimeter-ui.html`` is the web interface for the user to specify the service and IP @@ -85,9 +86,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. @@ -95,9 +96,15 @@ 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:: + + Sep 25 13:37:11 myhost tperimeter: User@192.168.0.2 Requested Service: sshd For Address: 10.0.1.23 + + HOW TO INSTALL ``tperimeter`` ----------------------------- @@ -118,7 +125,7 @@ their respective owners. First, you have to install the web interface. The example here -assumes you're using ``Apache``: +assumes you're using ``apache``: 1) Install ``tperimeter-ui.html`` in your desired location on the web site. We'll use ``/www/RemoteAccess`` for @@ -131,9 +138,9 @@ 3) You probably don't want the whole world to have access to this service, so it's pretty much mandatory you use - password access to the system. With ``Apache`` this means + password access to the system. With ``apache`` this means you'll need to install an appropriate ``.htaccess`` file - in this directory or otherwise secure it in your ``Apache`` + in this directory or otherwise secure it in your ``apache`` configuration file. 4) It is *highly* recommended that you require ``https`` when accessing @@ -154,11 +161,10 @@ so you may need to modify the script if your system has the ``python`` binary somewhere else. - 3) Now (very important) symlink the ``.htaccess`` file you - created in the previous step to this directory. This - prevents Eeeeeeevil Hackers from running the requestor - script directly from a URL and bypassing your website - security:: + 3) Now (very important) symlink the ``.htaccess`` file you created + in the previous step for the web interface to this directory. + This prevents Eeeeeeevil Hackers from running the requestor + script directly from a URL and bypassing your website security:: ln -s /www/RemoteAccess/.htaccess .htaccess @@ -177,7 +183,7 @@ "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 +``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 @@ -216,6 +222,11 @@ ALL + Note that ``10.0.1.``, ``64.2.3.1``, and ``ALL`` are names of + zero-length *files* easily created with the ``touch`` + utility. + + When ``hosts.allow`` get's rebuilt, this would result in two wrapper statements:: @@ -239,11 +250,10 @@ 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. + 3) Take care to name your service directories properly. They are + named for the *service* not the client program that accesses + it. ``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 @@ -319,15 +329,17 @@ 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 - be aware of this. If you don't like this sematic, you can - rewrite the ``rebuild-hosts.allow.sh`` file to suit your + 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 wrappers allow entries like ``64.23.`` to specify a range of addresses, you *cannot* enter such an IP specification via - the ``tperimeter`` web interface. + the ``tperimeter`` web interface. You also cannot specify + the host from which you desire access by using its name, only + its full IP quad address. 5) When initially logging into the ``tperimeter`` interface, the user probably does not know their "real" dynamic IP @@ -356,7 +368,7 @@ server has the inherent risk that it can be compromised. The key to minimizing such exposure is careful customization, integration, and testing. TundraWare Inc. makes **no** claims that this software will work without -security risks or compromise. The software is **experimental** and is +security risks or compromise. The software is **EXPERIMENTAL** and is provided **AS-IS**. It is up to you to take the necessary steps to ensure this system is appropriate for your environment.