Fork: 0
tundra / tperimeter
Browse code
Edits and cleanup.
master
1 parent 4cf93b2 commit b8497d1d3e8dcd92cdc0acf952a4c3f9b2e11a4b
@tundra tundra authored on 25 Sep 2006
Patch
Unified Split
Showing 1 changed file
View
91
■■■■■
 tperimeter.txt
.. 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 $
 
 
=====================================================
``tperimeter`` - A Dynamic TCP Wrapper Control System
 
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
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.
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
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``
-----------------------------
and ``rebuild-hosts.allow.sh`` should be set as executable by
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
our example.
ln -s tperimeter-ui.html index.html
 
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
this URL. There's no point in securing your system if the password
As written, it assumes that it is in ``/usr/local/bin/python``,
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
 
Next, you need to install the tcp wrapper rewrite subsystem:
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
``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
ftpd/
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::
 
ftpd: ALL :DENY
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.
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
directory in question and ``touch`` a file by that name. To remove
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
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
address - i.e., The address they need opened by ``tperimeter``
Any system that permits remote changes to the security environment of a
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.
 
There are several areas you should take particular care to audit to ensure