| | .. footer:: $Id: tperimeter.rst,v 1.1 2012/06/09 20:32:56 tundra Exp $ |
|---|
| | .. footer:: $Id: tperimeter.rst,v 1.2 2012/06/09 20:45:29 tundra Exp $ |
|---|
| | |
|---|
| | |
|---|
| | ===================================================== |
|---|
| | ``tperimeter`` - A Dynamic TCP Wrapper Control System |
|---|
| |
|---|
| | solve the problem simply and elegantly. A traveling user or a user |
|---|
| | whose IP address changes regularly simply logs into a secure web page |
|---|
| | and informs the system of their current IP address and which services |
|---|
| | they'd like to have enabled for them. ``tperimeter`` then fulfills |
|---|
| | the request - typically within 5 minutes or so - and grants access to |
|---|
| | the request - typically within 1 minute or so - and grants access to |
|---|
| | the system for that service from that IP address for a small window in |
|---|
| | time - again, 5 minutes it typical. This gives the user time to |
|---|
| | access the desired service before TCP Wrappers once again close the |
|---|
| | system to its default state. These semantics thus provide flexible |
|---|
| | remote access with an automatic reset to system default access |
|---|
| | control. |
|---|
| | time - 10 minutes is typical. This gives the user time to access the |
|---|
| | desired service before TCP Wrappers once again close the system to its |
|---|
| | default state. These semantics thus provide flexible remote access |
|---|
| | with an automatic reset to system default access control. |
|---|
| | |
|---|
| | |
|---|
| | HOW ``tperimeter`` WORKS |
|---|
| | ------------------------ |
|---|
| |
|---|
| | 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`` queue, but only if it has exceeded a certain age. |
|---|
| | This age is specified in the ``rebuild-hosts.allow.sh`` file with |
|---|
| | the ``${DURATION}`` variable. This means that the next time |
|---|
| | ``hosts.allow`` is rebuilt by the ``cron`` job, old "holes" |
|---|
| | ``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 |
|---|
| |
|---|
| | 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 |
|---|
| | that the "hole" ``tperimeter`` opens in your wrappers stays in |
|---|
| | 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. |
|---|
| | After a user has requested access, they must wait until this |
|---|
| | script runs again before the access is actually granted. So, this |
|---|
| | should be run in the ``root crontab`` every minute. |
|---|
| | |
|---|
| | 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 |
|---|
| |
|---|
| | |
tundra
authored
on 9 Jun 2012