FoxT ServerControl

BoKS ServerControl by Fox Technologies

Developer(s)	FoxT
Stable release	7.0
Operating system	Cross-platform
Type	computer security
License	Proprietary
Website	www.foxt.com

In computer security, BoKS ServerControl, by Fox Technologies, is a proprietary software product for the centralized management of user authentication and authorization (Role-based access control). The product used to be known as BoKS, or BoKS AccessControl, which is an abbreviation for the Swedish "Behörighet- och KontrollSystem", which translates as "Legitimacy and Control System". BoKS ServerControl was originally designed for use on Unix systems, Enterprise Linux distributions, and has recently been ported to Windows as well.

The product's key features include:

• Centrally defined access policies for user access to Unix based, Linux, and Windows servers.
• Real-time provisioning of security policies from a web interface or the command line.
• Wide range of configuration options, including various levels of security for specific (groups of) servers.
• Customized OpenSSH which allows fine-grained access control for SSH subsystems such as SFTP, SCP, X11 forwarding and tunneling, and automatic population of allowed_hosts files.
• Extensible beyond initial set of supported protocols through the use of Pluggable Authentication Modules.
• Provides tools for proactive security monitoring.
• Allows for interoperability with directory services such as NIS+, LDAP, LDAPS, Kerberos and Active Directory.
• Active Directory (AD) Bridging capabilities that allows UNIX/Linux systems to join AD and leveraging Kerberos (protocol) for user authentication.
• Interoperability (and the ability to define specifically one or a cascade of OTP code systems, Smartcard, PKI certificates, SSH User and Host keys, Kerberos session tickets, re-generated random passwords, and passwords with defined complexity for specific access authentication.

Operation

A basic BoKS ServerControl infrastructure consists of one master server, one or more replica servers and any number of server agent (server or desktop) systems. All communications between these hosts is encrypted ( using AES) and takes place over a reserved set of TCP/IP ports.

• The master server runs the main database and the management web interface. Any changes made to accounts, security policies and access routes are all made on the master server.
• Replica servers contain a read-only copy of the database which is asynchronously updated. Replicas handle most of the authentication and authorization requests sent by servers and desktops. Replicas can also be promoted to master server for the purpose of disaster recovery.

On the server, no modifications to the operating system are required when the agent is installed. The ServerControl daemons run alongside all the other processes, while certain key components of the environment are exchanged to enable ServerControl security. For example, on modern UNIX/Linux platforms (e.g. Solaris, HP-UX, AIX and Linux), PAM is reconfigured in such a way to hand off authentication and authorization requests to the local FoxT ServerControl daemons, which then communicates with a Replica over the network. On older versions of AIX 4.X, 5.0, 5.1, 5.2 and HP-UX 10.X (now all End of Lifed) that are not fully PAM compliant, one usually opts to replace the actual daemons (such as OpenSSH, telnet and ftp) with the FoxT versions which automatically hand over these requests.

A similar plug-in experience is used for the Windows Server agent (e.g. in Server 2008 the FoxT ServerControl agent is installed as a credential provider).

Once a user attempts to log into a server OS, the daemon in question will ask a FoxT ServerControl Replica to verify the provided user name and password (or other authenticator, see later). If these are found to match, FoxT ServerControl will perform a second check to see whether the user is actually allowed to log into this particular server, at this time and using this access method. If this second check is passed, the user is handed back to the login process to conclude the session in the usual fashion.

Common implementation assumes that enterprise (or service provider) provisioning workflow approval of identity occurs elsewhere. Typically user IDs and business groups reside in a corporate databases (Active Directory or LDAP), identity or role managers, and datafeeds. FoxT ServerControl becomes an enforcement and compliance reporting engine.

The BoKS ServerControl configuration may be modified in a number of ways.

• Through the management web interface.
• From the Unix/Linux command line.
• Automatic user and group updates from Active Directory and LDAP synchronization
• Integration with Role or Identity Managers thu APIs
• By dumping the security database, which is then manually edited and restored (not recommended).
• Early versions of FoxT ServerControl could be configured using a Tivoli/Plus module.

Terminology

The following terms are frequently used in the management of a BoKS ServerControl infrastructure.

Term	Explanation
host	Any system on the network, be it master, replica, server agent (client) or non-BoKS ServerControl host.
host group	A logical grouping of hosts. These can be multi-dimensional, a host can be in many intersecting hostgroups
user account	A combination of a username, plus its intended target host or hostgroup.
access route	One specific security authorization, assigned to a user account or a user class providing a specific linkage to a host or host group.
user class	A role description assigning a set of access routes to a user account.
access method	A communications protocol, such as telnet, ftp and SSH. Also includes su and suexec.
program group	A logical grouping of commands to be executed through suexec, which can be used in an access route.

A few notes:

• A unique user account is identified by the combination of its user name and the host or host group for which it has been defined. Multiple occurrences of a user name are allowed, as long as they are defined for different hosts or host groups. One common example is the Unix Root user account, which is always defined on the host level. Examples of user accounts: server1:root, SOLARIS:peter, ORACLE:patrick.
• A user account may have multiple user classes assigned to it. This allows one user account to perform work that is officially split across different departments. For example, SOLARIS:Peter may have both the user classes "SolarisThirdLine" and "BackupManagement".
• A host can be part of any number of host groups. This allows for fine-grained control over the provisioning of user accounts to specific servers. For example, server1 may be part of host groups SOLARIS, ORACLE and BACKUPEXEC, thus receiving all user accounts defined for those groups.
• Access routes can be assigned both to individual users, as well as to user classes. Thus one can allow server1:root to login only to the console of server1, while allowing SOLARIS:peter SSH access to all servers in host group SOLARIS.
• The term "BoKS ServerControl client" is being replaced in FoxT literature/website and documentation with the more common market term "Server Agent"

Supported protocols

BoKS ServerControl supports the following protocols: Serial & network port login(UNIX/Linux), console login (UNIX/Linux & Windows), su, suexec (UNIX/Linux equivalent to sudo), BoKS ServerControl runas (Windows equivalent to runas), secure RDP(Windows) secure telnet (UNIX/Linux), XDM and SSH (UNIX/Linux & Windows). The SSH protocol may be sub-defined and further split into ssh_sh (shell), ssh_exec (remote command execution), ssh_scp (SCP only), ssh_sftp (SFTP only), ssh_x11 (X11 forwarding), ssh_rfwd (remote port forwarding), ssh_fwd (local port forwarding) and ssh* (all of the above).

Older non-secure protocols: rlogin, rsh, rexec, ftp, rex, telnet are also supported for legacy purposes, but more typically are set up as banned across your server estate for compliance reasons. Support for PC-NFS and s-telnet has been deprecated.

Each protocol definition (defined in an Access Route) can be configured to change or require multiple factors of authentication

• all: use password authentication
• all: use X.509 certificate authentication
• all: use a One Time Password authentication like SecurID or Safeword
• for su: to use the user's own password to transition to a privileged account
• for suexec: optionally to keystroke log the session
• for SSH protocols: SSH keys generated by FoxT ServerControl, or to re-use existing SSH distributed keys.

A typical use case might be server support staff are challenged by a SecurID request to login on a server console in the computer room, and to use a PKI token on their own PC in their normal work area.

It is possible to plug other protocols into FoxT ServerControl, though this will require some customization. It is easiest if the software in question has support for Pluggable Authentication Modules, as there is a standard BoKS ServerControl module for PAM.

History

Over the years the Fox Technologies family of products has changed names and vendors a few times via product and company acquisition. It originated as BoKS UnixControl at DynaSoft AB in Sweden (1987), later Dynasoft International, after which it was sold to Security Dynamics, then absorbed into RSA Security (where the product was branded as part of the Keon family), and from 2002 latterly by TFS Technology (known as UnixControl or ServerControl). The company changed its name in 2004 to Fox Technologies Inc, moved its headquarters to the USA, and uses the sales/marketing label FoxT.

Apart from direct and VAR partner sales, the product has been sold under OEM licenses by other server vendors (HP, SUN) with alternate product names.

ServerControl was used in the early days of virtualization to secure the minimal OS of a Type 2 Hyper-visor, the most common use-case VMware releases prior to version 4.

The product has been and is resold as a white-label service enhancement by a number of service providers worldwide in the Telco, Oil&Gas, Mining, FMCG, Financial Services, Healthcare, Digital Movie Distribution, Retail and Government sectors. It is also used by Platform As a Service providers to isolate customer virtual infrastructures above the network level.

See also

• Identity management
• Role-based access control

External links

• Official Fox Technologies homepage
• International BoKS ServerControl Users Group
• BoKS ServerControl tutorials and howtos