TFS UnixControl White Paper - TFS Technology www.tfstech.com
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
TFS UnixControl
White Paper
Consolidate and simplify UNIX system
management with TFS UnixControl
TFS Technology
www.tfstech.comTFS UnixControl
Table of Contents
Overview 3
Introduction 3
TFS UnixControl Functionality 3
System Architecture Overview 6
Introduction 6
Architecture 6
About TFS Technology 14
TFS UnixControl / 2TFS UnixControl
The TFS Technology Vision: “Lead the world in providing enhancements to existing infrastructure,
simplifying usage and administration with profound security using
products and services that add value to the customer.”
Overview
Introduction
The TFS UnixControl solution makes use of the TFS BoKS Manager and the TFS BoKS Client
for UNIX, and is a comprehensive security system for multi-vendor platforms in a UNIX network
with many hosts, many users and stringent security requirements. Designed to meet the
security needs of modern computing environments, it provides for lock-down, centrally
managed access control and audit trails.
TFS BoKS Manager provides the base for the solution and contains the security database and
all functionality to run TFS UnixControl. TFS BoKS Client for UNIX runs on the UNIX client
servers, relying on the information that TFS BoKS Manager has stored in its security database.
The TFS UnixControl solution supports the variety of UNIX brands; see the TFS web site
www.tfstech.com for further information. TFS UnixControl does not touch the kernel when
integrating with the UNIX system. It can be installed in a heterogeneous UNIX environment,
and still will function on all supported platforms.
TFS UnixControl Functionality
Simplified and centralized system administration in heterogeneous UNIX
Environments
The TFS UnixControl security database is a central repository that contains information about
components such as User Accounts, Credentials, user Access Routes, Hosts within the
managed network. System administrators use a smooth Graphical User Interface (GUI) or a
flexible and powerful Command Line Interface (CLI) to manage the security database. The
TFS BoKS Manager also allows the assignment of a limited-access GUI to sub-administrators.
This means that different tasks and groups of users within the product can be handled by
different administrators within an organization. TFS UnixControl simplifies user administration
in a heterogeneous UNIX environment by handling creation, modification and removal of users
on over a hundred machines, running different UNIX brands, at a click. Each TFS UnixControl
port to a particular UNIX brand is specially adapted to the standard features existing on that
machine for user administration. TFS UnixControl also allows the grouping of hosts into Host
Groups, making for smoother administration in managing users.
Scalability
In addition to the central TFS BoKS Manager Master server, the product also allows the setting
up of Replica servers, which house a read-only copy of security database to provide fast and
fail-over access within the managed network. The UnixControl solution also allows for setting
up different TFS BoKS Manager domains for scaling purposes.
Fail-over
TFS BoKS Manager contains mechanisms that handle the failure of both Master server and
Replica servers (A Replica server houses a read-only copy of the security database). Each
Client server in the domain, i.e. a machine installed with BoKS Client, TFS Desktop or TFS
Agent, that requires information from the security database can be configured to ask the Master
server as well as Replica servers. If the Master server is down for a relatively long period, any
Replica server can be promoted to Master. This converting function can be used to restart the
administration of the system .
Mixed Unix environments
TFS BoKS Manager supports the major UNIX operating systems, integrating with the operat-
ing system as much as possible without sacrificing functionality or touching the kernel. For
further information on supported platforms, please contact a TFS Sales representative.
TFS UnixControl / 3TFS UnixControl
Import of existing users
TFS BoKS Manager has the functionality to import users from existing password files, TCB
(trusted computer base), YP/NIS, NIS/NIS+, and databases that support LDAP communication.
This makes it simple to begin using the product in an existing infrastructure.
LDAP synchronization of user data
TFS UnixControl allows for automatic periodical, as well as manual, synchronization of user
data with databases supporting the LDAP protocol.
Blocking users
TFS UnixControl contains user blocking mechanisms:
• Automatic blocking. TFS UnixControl blocks the user after a defined number of failed
login attempts. The administrator can configure this number, as well as unblock
blocked accounts.
• Manual blocking. The administrator has the capability to manually block a specific
user, users' access to certain machines, or users' access to the UnixControl system.
The block user functionality can be used when a user is on temporary leave or has
not yet begun his or her employment.
Improved Unix security
Authentication of users is based on the information in the security database. Support for two-
factor authentication, and the necessity that a user have a matching access route as well as
an account to access the system, improves security.
Password policies
All password changes must pass TFS UnixControl password policy handling. TFS UnixControl
contains rules for password formats, expiration period, lifetime, as well as a function that allows
the use of a 'ban password' dictionary. The dictionary is able to handle regular expressions for
ban password patterns.
Timeout
TFS UnixControl contains central timeout support for UNIX users. The user can either be
logged out or have screen activity locked (the user must run XDM or dtlogin, or use a vt100-
compatible terminal to be eligible for the locking function).
UNIX to UNIX SSO
TFS UnixControl enables the use of encrypted single sign-on telnet inside or between TFS
UnixControl domains. TFS UnixControl also provides a SSHD to be used for encrypted con-
nections as well as Single Sign-On, if wanted. These functionalities provide an easy and secure
way to alternate among machines protected TFS UnixControl.
Monitoring files and directories
TFS UnixControl contains a monitoring function, which surveys files and directories. This
function detects when someone has tampered with any monitored files or directories, and
sends an alarm log when such an event has occurred. Configuration of monitored files and
directories is simple, and can therefore easily be adapted to the needs of an organization.
Integrity checks
The TFS BoKS Manager integrity check scans the system for known vulnerabilities. The
integrity check creates a report of known issues as well as suspicious file and directory
permissions, ownership and content. The administrator can configure the Integrity Check
function to perform the checks at intervals deemed necessary to maintain a healthy system, as
well as exclude and include security warnings. This is useful in keeping the number of
security warnings down. For example, if the integrity check produces a certain warning every
time, but this warning is considered a normal situation, the administrator can exclude it to
reduce the number of warnings produced, thereby increasing the visibility of security warnings
that he or she considers serious.
Backup and Restore of security database and files
TFS BoKS Manager contains the function to back up and restore the database and all
security-related files. This feature makes it easy to restore the system if the Master experiences
problems.
TFS UnixControl / 4TFS UnixControl
Auditing trails
TFS BoKS Manager contains audit capability for all security-related events, with a central
logging file in which all security-related events are stored, as well as the tools to present the
file. The logs can also easily be exported to a format that allows for analysis with other log tools.
TFS BoKS Manager has an editable alarm log with the capability to trigger events. Using this
function in TFS BoKS Manager, the administrator has the capability to trigger his or her own
events, such as as pager and special email.
Remote Administration
TFS UnixControl supports encrypted remote administration using a browser with SSL together
with a smart card, virtual card or RSA SecurID token for authentication of the administrator.
CA
TFS UnixControl contains complete CA-server functionality, allowing an organization to make
virtual cards for administration purposes.
TFS UnixControl / 5TFS UnixControl
System Architecture Overview
Introduction
The TFS UnixControl solution gives easier administration of users and hosts and higher
security in an existing UNIX environment.
The next sections describe the architecture and functions this solution encompasses.
Architecture
TFS BoKS Manager is the server base platform for the TFS UnixControl solution. This section
describe the basic architecture of TFS UnixControl.
In a network, you can have several installations of the TFS UnixControl solution. Each
installation is called a security domain and is made up of one BoKS Master server and one or
more BoKS Replica servers.
A Master server is the central point at which the administrator and sub-administrator perform
administration of the security domain. Each Replica server houses a read-only copy of the
security database and is used for fail-over, scaling and load balancing.
The figure below shows an example of how a very simple domain could look. Note that this
domain does not contain the TFS BoKS Client for UNIX:
TFS UnixControl / 6TFS UnixControl
All updates of the security database are handled by the Master server. When an update occurs,
the Master server updates its own database and then sends this update to the Replica servers'
databases. When running the TFS UnixControl solution, the Master server also keeps
the/etc/passwd file or TCB updated on machines belonging to the security domain.
Important for auditing is that the log files are replicated, thus no information is lost if the Master
server experiences problems. By default, the log file is replicated to all Replica servers. To limit
log traffic, the sending of log replication can be limited to only the most important Replica
servers.
Internal Communication and daemons
The internal communication, which uses TCP/IP in a security domain, is encrypted using DES
56-bit or RC5 128-bit. The communication can be divided into the three areas updating,
replication and requests.
TFS UnixControl allocates four ports for communication, which are registered at IANA. Each
port has its own daemon taking calls. The ports are as follows:
6500 - Used by the master daemon. The master daemon updates the Master server's data
base, as well as initiates the replication.
6501 - Used by servm daemon. The servm daemon has the task of updating the Replica
server databases.
6502 - Dedicated for any requests. The daemon servc listens on this port to handle requests
for authentication and authorization.
6503 - Used for updating /etc/passwd or TCB, through the clntd daemon.
These are the default ports for a domain and can be changed if another domain needs to be
installed, or if the ports are already dedicated. Changing the ports is done easily, editing the
/etc/services file.
TFS UnixControl / 7TFS UnixControl
For remote administration purposes, TFS BoKS Manager uses port 6505. This communication
is encrypted. An organization can use a different port if desired, simply by changing an
environment variable.
When two TFS UnixControl machines communicate, they use node keys as a shared secret for
encryption. These node keys are given for each machine during setup, and must be registered
on the Master.
When the node key is given it will be md5 hashed (128-bit). The hash is used as the
encryption key.
It is crucial that the node keys are kept secret; otherwise the security of the TFS UnixControl
domain can be jeopardized.
Replication
TFS UnixControl uses database replication to avoid downtime in a production environment. All
replication is handled by the Master, which sends updates to the Replica(s) when a change has
occurred. Using a hierarchy as a replication model, TFS BoKS Manager has an easy
replication model that has matured and proven to be stable even in mission-critical
environments.
Load balancing
TFS UnixControl contains an in-build load balancing. Both Master and Replica servers operate
a queue that handles all incoming requests. The server monitors the number of requests in its
queue and begins to slow the process of taking calls when this number reaches a certain limit.
It also has a maximum incoming request limit, at which it stops taking calls altogether. This is
crucial since all TFS UnixControl servers time-stamp each received request and have an
internally set limit of 20 seconds for handling a request.
There are two ways in which TFS UnixControl clients can call the Master and the Replica
servers, using broadcast (default) or addressing the servers directly.
TFS UnixControl / 8TFS UnixControl
Fail-over
Thanks to the TFS UnixControl replica system , it is simple to convert a Replica to a Master if
necessary. The convert program performs this conversion in less than one minute.
GUI and CLI
The Graphical User Interface (GUI) is based on HTML code generated by TCL (This makes
modification possible. NOTE! When upgrading or patching your system it is possible that the
settings change back to their original state). The GUI is equipped with default values, making
it easy to start the security administration of the system. The http server uses SSL, which
ensure that the connection between the browser and the http server will always be encrypted.
For a remote administration connection, the administrator must have a certificate or SecurID
token to authenticate, as well as an access route to the system in question.
The Graphical User Interface also has built-in access control, allowing restricted menu access
for sub-administrators. The configuration of a sub-administrator is easily performed in the GUI.
The Command Line Interface (CLI) is a powerful tool that invokes a complete set of programs,
allowing the administrator to script functions as well as configure the security system with
tailor-made values, something that is not possible in the GUI. The CLI also contains script
templates that can be used to perform tasks in the TFS UnixControl GUI after a user has been
added, modified or removed.
User handling
A user in TFS UnixControl always belongs to one or several machines installed with
TFS UnixControl. If systems already have users configured, TFS UnixControl can import these.
Users can be imported from any file in /etc/passwd format and/or NIS. Users being imported
are added to either a single host or a predefined group of machines (Host Group). The use of
Host Groups makes it easy to change the machines to which a user or group of users belongs.
The administrator simply adds or deletes hosts in a Host Group.
NOTE! TFS recommends that system users be added on a per-machine basis and ordinary
users be added to a Host Group.
TFS UnixControl can synchronize with an LDAP directory. This enables the addition and
removal of users via LDAP synchronization. In specifying an LDAP path, user templates can
be used to predefine the values a user should have when created in the security database.
TFS UnixControl creates home directories and sets up profile files for each host belonging to
a Host Group when a user is created. TFS UnixControl also adds, modifies and deletes the
user in a local /etc/passwd file, TCB or in an NIS database.
TFS UnixControl has one prerequisite before configuration of the system can be performed: All
UIDs for a particular user must be the same for all the systems to which the user is to be added.
TFS has developed a tool, available upon request, that helps to implement this.
Authentication, Authorization and Auditing
Authentication is the process of verifying that users are who they claim to be, for example, by
requesting that the user present his or her password or SecurID passcode.
The authentication method is the means by which an authentication is performed. Examples of
authentication methods are ordinary passwords and one-time passwords. One-time
passwords, the use of which is called two-factor authentication, are virtually impossible to
falsify. TFS UnixControl supports one-time SecurID password tokens for users. In addition to
granting or restricting user access to individual hosts based on access methods, TFS
UnixControl can be used to demand a specific Authentication Method as well, allowing
Administrators to define rules that, for instance, will enforce two-factor authentication for
access to protected hosts.
Authorization is the process of checking that a user is allowed to access the system, program
etc. TFS UnixControl mainly checks standard UNIX services for this type of access. TFS
UnixControl does not, however, check any ports, thus making it possible for a user with more
privileges than necessary to create a program to pass the TFS UnixControl checks. This issue
TFS UnixControl / 9TFS UnixControl
must be handled within an organization; it is crucial to assign users only the specific access
rights that he or she requires.
Auditing is the process of logging events that occur in the system - All actions that involve
TFS UnixControl are logged. The resulting logs have proven to be an excellent base for
passing an audit session.
Access Route
An Access Route specifies how, from where, and when a user may access a particular host or
group of hosts. An Access Route includes:
• User or User Class
• Access method (telnet, ftp, login, etc.)
• Source and destination computers ("from host", "to host")
• Day of week and time of day when access is to be granted
TFS UnixControl allows you to control access to UNIX environments by assigning Access
Routes to users individually or by User Class.
A Restricted Access Route is an Access Route that disallows, that is, denies, access. In all
other regards, a restricted Access Route is specified by the same parameters as and treated
as an ordinary, or non-restrictive, Access Route.
User Class
A User Class is a collection of Access Routes defined by your organization for ease in
managing access rights. Individual users are normally, but not necessarily, assigned to a User
Class.
Host Group
A Host Group is a collection of UNIX host computers defined by the System Administrator for
ease in managing access rights or users. Individual hosts are normally, but not necessarily,
members of one or more Host Groups. If a user account is added to a Host Group,
TFS UnixControl will maintain the user account on all the individual hosts included in the group.
Furthermore, Access Routes can be based on Host Groups rather than individual hosts, which
makes it easy to define a structured scheme for access control in very large networks as well.
Access Methods
An Access Method is a program such as telnet, ftp, r-commands and login that is used to
access a host. Depending on option choices at installation, TFS UnixControl exchanges some
or all of the original access programs in the operating system with its own counterparts. On
machines that have a sufficient PAM module, TFS UnixControl plugs in to the chain instead of
exchanging the service. Below is a description of the protected services:
Module Access Method What the UC/UPS module does
login LOGIN Supports login from ttys to a target host/Host
Group. Authentication requires username
and code (password or passcode). All login
requests are registered, and log entries
contain time, tty, target machine, username
and method of authentication.
telnetd TELNET Supports login from a source host/Host
Group to a target host/Host Group. Authen-
tication requires username and code. This
access method can also be configured to
provide SSSO for communication between
servers using BOSK/BOSAS inside the
TFS UNixCOntrol domain. All requests are
registered, and log entries contain time,
source and target machine names, user
name and method of authentication.
TFS UnixControl / 10TFS UnixControl
(continued)
Module Access Method What the UC/UPS module does
rlogind RLOGIN Supports remote login from a source
host/Host Group to a target host/Host Group.
Authentication requires username with target
user code or no code at all. All requests are
registered and log entries contain time,
source and target machine names, target
username and method of authentication.
rshd RSH Supports rlogin from a source host/Host
Group to target host/Host Group. Authen-
tication requires target username with target
user code. All requests are registered and
log entries contain time, source and target
machine names, target username, method
of authentication and command given. This
method also includes remote copy, rcp.
rexecd REXEC Supports rexec from a source host/Host
Group to target host/Host Group. Authen-
tication requires target user code. All
requests are registered, and log entries con-
tain time, source and target machine name,
target username, source username, method
of authentication and command given.
ftpd FTP Supports ftp from a source host/Host
Group to target host/Host Group. Authen-
tication requires target username and target
user code. All calls will be logged in the log
database with time, from machine, target
machine, target username and method of
authentication.
su SU Supports su from a tty to target user at
host/Host Group. Authentication requires
target username and target user code or
source user code, provided the user is
allowed to su to another user using the
code for the source user as authentication.
All calls will be logged in the log database
with time, from machine, target machine,
target username, source username, and
method of authentication.
suexec SUEXEC Supports running an allowed command with
suexec on a target machine as root, given
source user code. All calls will be logged in
the log database with time, from machine,
target machine, source user name, com-
mand and method of authentication.
xdm XDM Supports xlogin from a source host/Host
Group to target host/Host Group. Authen-
tication requires target username and target
user code. All calls will be logged in the log
database with time, from machine, target
machine, target username and method of
authentication.
ssh SSH Supports ssh login from a source host/Host
Group to target host/Host Group. All calls
will be logged in the log database with time,
from machine, target machine, target user
name and method of authentication.
TFS UnixControl / 11TFS UnixControl
On the Client side, users may access a TFS UnixControl-maintained host through any of the
various access programs that TFS UnixControl supports.
Login requests will vary depending on which access program is used. For example, a service
such as rshd could grant access to a system without a password being required, and su could
accept the user's own password rather than the password of the target user. However, in most
cases a username and the corresponding password or, if the Access Route requires
two-factor authentication, and SecurID PASSCODE, will be required.
Suexec can be used to perform root commands without login to the actual root account. In the
access route administration, it is possible to define the commands to allow for different users.
All suexec commands are logged.
TFS BoKS Client for UNIX authentication
When a user attempts to log in at the TFS BoKS Unix client node, the node begins by locating
an available authentication server, that is, a BoKS Master or Replica server. The login request
is then forwarded to the first server that responds, which compares the login request with the
settings in the security database. It first checks if the access route as such has any particular-
ly settings, for example, whether the access route requires SecurID or should be encrypted.
Next, the Client requests the username (this is not applicable in a single-sign-on connection)
and sends it to the authentication server, asking the server if anything special is required for
this user to gain access, for example an RSA SecurID passcode. In the last step of the authen-
tication, the Client sends the passcode or password to the server for determination as to
whether the user is allowed to access the machine. After the authentication server has
processed the information, the sequence ends with the Client sending a log entry to the Master.
Whether or not the login request is granted, the event is written to the TFS UnixControl log.
Node Key
A Node Key is a special password given to each host within the TFS UnixControl domain. Node
Keys are used to secure internal communication between hosts and to authenticate a BoKS
Client when it communicates with the BoKS Master or Replicas. The Node Key also
comprises part of the unique session key used for encryption during the secure transmission
between BoKS Client and Master.
Integrity check
TFS UnixControl contains an integrity check that can be used to find common problems with-
in a system. The integrity check is run by cron and generates a report that is sent to the
Master for further analysis. The integrity check controls the following:
• rc files - Checks if /etc/rc and the programs referenced in the rc files are writable.
This check also includes /etc/inittab and /sbin/init and files referenced from these
files.
• Crontab files - Checks the root crontab for writability. The commands used in the
crontab file and any embedded file references are also checked for writability. Each
command is checked to ensure use of absolute path names.
• File permission check - Scans all local file systems to find suspicious permissions,
names, or ownerships. This is performed through a comparison against a list
of known permissions and ownerships in the files /etc/opt/boksm/bic/checks.conf,
./permlist.conf, and ./system.conf. This check also includes search device nodes
located outside /devices or /dev, and setuid files writable by no one but the owner.
Setuid root files are always reported, unless they are present in the list of known
permissions and ownerships.
• Mounted File system; Device files - Checks permissions in the /etc/fstab. Writable
and world readable devices are reported.
• NFS exported and mounted file systems - Checks security problems related to
NFS, such as unrestricted exports and mounting with suid enabled.
• Passwd file - Checks the format of the passwd file(s). Lines that are possibly illegal
are reported.
• Unix Mailbox Directory- Checks the files in the mail directories for suspicious
names, modes, permissions, or types. The check reports if a file is not named after
its owner, and if a file is readable by anyone other than the owner or a special mail
group.
TFS UnixControl / 12TFS UnixControl
• Inetd config file - Checks the inetd.conf and /sbin/inetd for vulnerabilities. This
also includes programs called from inetd.conf as root.
• TFTP configuration - Checks that tftp is not configured in a way that any file on
the system can be accessed via tftp from anywhere.
File monitoring
The file-monitoring daemon surveys directories and files. It checks inode number, size, per-
missions and modification time and can operate on three different default levels (low, medium
and high). Below is an example of what these levels contain.
Low:
$BOKS_sbin (as default /opt/boksm/sbin)
$BOKS_lib (as default /opt/boksm/lib)
$BOKS_lib/bic
/sbin/su
/usr/lib/iaf/scheme
/usr/bin/passwd
/usr/bin/yppasswd
/usr/sbin
Medium:
$BOKS_sbin (as default /opt/boksm/sbin)
$BOKS_lib (as default /opt/boksm/lib)
$BOKS_lib/bic
/sbin/su
/usr/lib/iaf/scheme
/usr/bin/passwd
/usr/bin/yppasswd
/usr/sbin
/usr/lib
High:
$BOKS_sbin (as default /opt/boksm/sbin)
$BOKS_lib (as default /opt/boksm/lib)
$BOKS_lib/bic
/sbin
/usr/bin
/usr/sbin
/usr/lib
The file $BOKS_etc/files (as default /etc/opt/boksm/files) can be used to configure the file
monitoring daemon to survey files or directories of your choice. The default time time between
checks is 20 minutes, but can be reconfigured through the CLI.
Audit
TFS UnixControl contains a logging system that covers activities that influence system
security, such as changes to security parameters (collected in the System Log) and access
attempts (collected in the Session Log). Some events are considered very serious - these are
called alarm events. Alarm events can be sent to any program of the administrator's choosing.
Edit the alarmlogs file to define what is to be considered an alarm event. The table below shows
the major log events:
Log Type Event Alarm
System Any action carried out in TFS UnixControl that affects the NO
security database. This includes creating a user, changing
security parameters, and registering a new host.
System Results of file monitoring YES
Session Logins and logouts, including network sessions NO
Session Unsuccessful login attempts, inlduing network login attempts NO
Session Attempts to use non-interactive access programs NO
Session Attempts to use su YES
Session Password changes NO
Note that all logs are text-based and can be exported and sent to another system for analysis
or surveillance purposes.
TFS UnixControl / 13TFS UnixControl
One System, Many Solutions
TFS Technology achieves synergy between its different solutions, as they are all part of the
same standards-based system that protects critical applications while complying with enter-
prise-wide security policies. It's central component, the TFS BoKS Manager, provides not only
central administration, but also a central point of security information for other applications.
A number of solutions are available in the system including UNIX administration, file
encryption, secure messaging, email directory synchronization, and many more.
TFS currently offers subsets of these services as individual licenses.
About TFS Technology
TFS Technology is an international award-winning provider of solutions that simplify usage
and administration of existing infrastructure while providing profound security for today's
successful businesses. With solutions adopted in more than 10,000 organizations spanning
30 countries, TFS Technology leads the world in providing value-added products and servic-
es to the customer.
The history of the company's technology dates back to 1986 at the DynaSoft organization with
the initial development of what is known today as TFS BoKS. In 1992, the development work
of the email security and connectivity products were initiated within the TenFour organization.
In 2001, TFS Technology was established as a separate entity from TenFour. focusing strictly
on product development of email security and connectivity solutions.
In 2002, TFS Technology acquired the key management and file encryption products from
RSA Security Inc., joining both product families together and strategically positioning
TFS Technology as a comprehensive provider of e-security and infrastructure-enhancing
solutions.
Today, TFS Technology's management team consists of the original inventors and developers
of both successful product families, and is dedicated to continuing their strong product
reputation of developing easy-to-use solutions.
TFS Technology US TFS Technology TFS Technology UK
Inc. Sweden AB Ltd.
info@tfstech.com info@tfstech.com info@tfstech.com
+1 703 263 1700 +46 18 16 00 00 +44 08707 330 104
www.tfstech.com
Copyright 2003 TFS Technology. All rights reserved.You can also read
