Fork: 0
tundra / tperimeter
Browse code
First complete version.
master
1 parent c2123da commit 7d2608f0c5efd74e5e8b1dacba8fe9bdc61a6d11
@tundra tundra authored on 25 Sep 2006
Patch
Unified Split
Showing 1 changed file
View
215
■■■■■
 tperimeter.txt
.. 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 $
 
 
=====================================================
``tperimeter`` - A Dynamic TCP Wrapper Control System
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:
 
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
model operates only at the time of the initial connection request.
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.
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.
 
The queue where ``tperimeter`` requests are initially deposited and
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
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``
-----------------------------
2) Copy the ``rebuild-hosts.allow.sh`` file to this directory.
 
 
 
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``
--------------------------