Product features and benefits
New features in 3 F4
SCB is a proxy gateway: the transferred connections and traffic are inspected on the application level (Layer 7 in the OSI model), giving control over protocol features like the authentication and encryption methods or the permitted channels.
Authentication and authorization
SCB provides two-factor authentication and other ways to improve your control and accountability over users accessing your servers.
To make integration into your network infrastructure smooth, SCB is available both as hardware and virtual appliance, and supports several different operation modes.
SCB is configured from a clean, intuitive web interface. The roles of each SCB administrator can be clearly defined using a set of privileges.
SCB can selectively permit or deny access to certain protocol-specific channels. For example, it can enable terminal sessions in SSH, but disable port-forwarding and SCP, or enabled desktop access for the Remote Desktop Protocol, but disable file and printer sharing.
SCB supports the following protocols:
- The Secure Shell (SSH) protocol (version 2) used to access Unix-based servers and network devices.
- The Remote Desktop Protocol (RDP) versions 5-7 used to access Microsoft Windows platforms, including 2008 Server and Windows 7.
- HTTP/HTTPS protocol used for administrative access to the web interfaces of various devices and applications, for example, routers, firewalls, appliances, web-services, and so on.
- The X11 protocol forwarded in SSH, used to remotely access the graphical interface of Unix-like systems.
- The Telnet protocol used to access networking devices (switches, routers) and the TN3270 protocol used with legacy Unix devices and mainframes. TLS or SSL encryption for Telnet, and TN3270 is also supported.
- The Virtual Network Computing (VNC) graphical desktop sharing system commonly used for remote graphical access in multi-platform environments. TLS or SSL encryption for VNC is also supported.
- VMware View Clients using the Remote Desktop (RDP) display protocol to access remote desktops.
- Citrix ICA protocol to access virtual desktop and application server infrastructures, designed by Citrix Systems. SCB is the first client- and server independent solution, which can transparently control and audit XenDesktop and XenApp deployments. Reliable connections also known as Common Gateway Protocol (CGP) are also supported.
- Terminal Services Gateway Server Protocol, so SCB can act as a Terminal Services Gateway (also called TS Gateway or Remote Desktop Gateway).
Starting with SCB 3.0 it is possible to audit file-transfers over SCP and SFTP by listing the file operations and extracting the transferred files for later analysis. With this new feature both managed file transfer (MFT) and ad-hoc network copies can be monitored, which is useful for forensics investigations or data leakage incidents. Auditors can search for file transfers on the SCB search interface, download the audit-trails containing specific files, and save the actual transferred content with the Audit Player for further inspection.
SCB can monitor the traffic of certain connections in real time, and execute various actions if a certain pattern (for example, a particular command, window or text) appears in the command line or on the screen. Since content-monitoring is performed real-time, SCB can prevent harmful commands or programs from being executed on your servers. SCB can also detect numbers that might be credit card numbers. The patterns to find can be defined as regular expressions.
The following actions can be performed:
- Log the event in the system logs.
- Immediately terminate the connection.
- Send an e-mail or SNMP alerts about the event.
- Store the event in the connection database of SCB.
Authentication and authorization
To avoid accidental misconfiguration and other human error, SCB supports the 4-eyes authorization principle. This is achieved by requiring an authorizer to allow the administrators to access the server. The authorizer also has the possibility to monitor the work of the administrator real-time, just like they were watching the same screen.
The 4-eyes principle can be used for the auditors as well; SCB can use multiple keys to encrypt the audit trails. In this case, multiple decryption keys are needed to replay the audit trails, so a single auditor on his own cannot access every information about your systems.
SCB can require users to perform gateway authentication, meaning that a user must authenticate on SCB as well. This additional authentication can be performed on the SCB web interface, providing a protocol-independent, outband authentication method. In this way the connections can be authenticated to the central authentication database (for example LDAP or RADIUS), even if the protocol itself does not support authentication databases. In addition, connections using general usernames (for example root, Administrator, and so on) can be connected to real user accounts.
For SSH and RDP connections, usermapping policies can be defined. A usermapping policy describes who can use a specific username to access the remote server: only members of the specified local or LDAP usergroups (for example administrators) can use the specified username (for example root) on the server.
SCB allows you to define connections; access to a server is possible only from the listed client IP addresses. This can be narrowed by limiting various parameters of the connection, for example, the time when the server can be accessed, the usernames and the authentication method used in SSH, or the type of channels permitted in SSH or RDP connections. Controlling authentication means that SCB can enforce the use of strong authentication methods (public key) and also verify the public key of the users. Also, SCB can authenticate the users to an external user directory. This authentication is completely independent from the authentication that the user performs on the remote server.
The following parameters can be controlled:
- The IP address of the client machines allowed to access the server.
- The group of administrators permitted to access the server (based on username black- and whitelists or LDAP groups) when using SSH or RDP6 with Network Layer Authentication.
- In addition to the authentication performed on the remote server, it is also possible to require an additional, outband authentication on the SCB web interface. Authorization can be based on this outband authentication as well.
- The authentication method (for example, password, public-key, certificate) required to access the server using SSH.
- The time period when the server can be accessed (for example, only during working hours).
- The type of the SSH or RDP channel permitted to the server (for example, SSH terminal or port forward, RDP file sharing, and so on).
Credential store offers a way to store user credentials (for example, passwords, private keys, certificates) and use them to login to the target server, without the user having access to the credentials. In this way users only have to authenticate on SCB with their usual password (that can be stored locally on SCB or in your central LDAP database). If the user is allowed to access the target server, SCB automatically logs in using the data from the credential store.
In addition to storing credentials locally, SCB integrates smoothly to Enterprise Random Password Manager (ERPM), Lieberman Software's privileged identity management solution. In this way the passwords of the target servers can be managed centrally using the ERPM, while SCB ensures that the protected servers can be accessed only via SCB — since the users do not know the passwords required for direct access.
Audit & Forensics
SCB records all sessions into searchable audit trails, making it easy to find relevant information in forensics or other situations. Audit trails can be browsed online, or followed real-time to monitor the activities of the administrators. All audit trails stored on SCB and the archiving server are accessible from SCB's web interface. The Audit Player application replays the recorded sessions just like a movie – all actions of the administrators can be seen exactly as they appeared on their monitor. Audit trails are indexed by a separate indexing-server. This makes the results searchable on the SCB web GUI. Audit player enables fast forwarding during replays, searching for events (for example, mouse clicks, pressing Enter) and texts seen by the administrator. It is also possible to execute searches on a large number of audit trails to find sessions that contain a specific information or event. SCB can also execute searches and generate reports automatically for new audit trails.
SCB is an independent device that operates transparently, and extracts the audit information directly from the communication of the client and the server. This prevents anyone from modifying the audited information – not even the administrator of SCB can tamper the audit trails, which are timestamped, encrypted, and signed.
In addition to recording audit trails of the inspected protocols, embedded protocols (for example, other protocols tunneled in SSH, port-forwarding) and transferred files can be recorded as well. Recorded files from SCP and SFTP connections can be extracted for further analysis. It is even possible to convert the audited traffic into packet capture (pcap) format to analyze it with external tools.
Connections can be searched form the SCB web interface based on their metadata and their actual content as well. All audit trails are indexed on a separate indexing-server, enabling fast forwarding during replay, searching for events (for example, mouse clicks, pressing the Enter key) and texts seen by the administrator. Reports and automatic searches can be configured as well. To protect the sensitive information included in the communication, the two directions of the traffic (client-server and server-client) can be separated and encrypted with different keys, thus sensitive information like passwords are displayed only when necessary.
In addition, SCB supports creating custom reports, including user-created statistics and charts based on search results, the contents of audit trails, and other customisable content. Reports from custom queries executed on the databases of SCB can be created as well. Custom report examples: SSH-exits, distribution of target hosts or remote user name statistics.
Auditing is usually based on the logs generated on the audited server. This model is inherently flawed, as logs of interactive events are usually not too detailed, and there is no way to ensure that the logs stored on or sent by the server are not manipulated by an administrator or attacker. But SCB is an independent device that operates transparently, and extracts the audit information directly from the communication of the client and the server. This prevents anyone from modifying the audited information – not even the administrator of SCB can tamper the encrypted audit trails. SCB also generates detailed changelogs of any modification of its configuration.
To make integration into your network infrastructure smooth, SCB supports different operation modes: bridge, router, and bastion mode. To simplify integration with firewalled environments, SCB supports both source and destination address translation (SNAT and DNAT).
In Bridge mode, SCB acts as a network switch, and connects the network segment of the administrators to the segment of the protected servers at the data link layer (Layer 2 in the OSI model).
In Router mode, SCB acts as a transparent router connecting the network segment of the administrators to the segment of the protected servers at the network layer (Layer 3 in the OSI model).
Administrators can address only SCB, the administered servers cannot be targeted directly. The firewall of the network has to be configured to ensure that only connections originating from SCB can access the servers. SCB determines which server to connect based on the parameters of the incoming connection (the IP address of the administrator and the target IP and port).
SCB can operate in nontransparent mode as well, extracting the address of the target server from the inspected protocol itself. Nontransparent operation is mainly used in Bastion mode, and simplifies the integration of SCB into the network infrastructure.
Integration to user directories
SCB can connect to a remote LDAP database (e.g., a Microsoft Active Directory server) to resolve the group memberships of the users who access the protected servers. Rules and policies can be defined based on group memberships. When using public-key authentication in SSH, SCB can authenticate the user against the key or X.509 certificate stored in the LDAP database.
Administrators and auditors accessing the web interface of SCB can also be authenticated to an LDAP database. RADIUS authentication (e.g., using SecureID) is also supported both for accessing the web interface, and also to authenticate the audited SSH sessions.
API for remote SCB access and integration
Web Services based remote API (RPC API) is also available to manage and integrate with SCB. The SOAP-based API allows you to access, query, and manage SCB from remote applications. Accessing SCB with the API offers the following advantages:
- Integration into custom applications and environments (e.g. helpdesk ticketing systems)
- Flexible, dynamic search queries and management from external applications (e.g. system monitoring tools).
SCB is also available with high availability (HA) support. In this case, two SCB units (a master and a slave) having identical configuration operate simultaneously. The two units have a common file subsystem; the master shares all data with the slave node as soon as the data is received: every configuration change or recorded traffic is immediately synchronized to the slave node. If the master unit stops functioning, the other one becomes immediately active, so the protected servers are continuously accessible. SCB1000d and larger versions are also equipped with dual power units.
SCB is officially supported on VMWare ESX systems as a virtual appliance, which is mainly useful in virtual and cloud environments. Note that certain platform-specific limitations apply.
SCB appliances are built with high performance, energy efficient, and reliable hardware that are easily mounted into standard rack mounts. A 64-bit operating system is used to power SCB, utilizing the underlying hardware to the fullest.
|SCB N1000||1||No||INTEL X3430 2,4GHz QUAD||4 GB RAM||2x 1 TB SATA||Software raid||Yes|
|SCB N1000d||2||Yes||2x INTEL XEON E5620 2,4GHz||6x DDR3 4GB||2x 1 TB SATA||Software raid||Yes|
|SCB N10000||2||Yes||2x INTEL XEON E5620 2,4GHz||6x DDR3 4GB||12x 1 TB SATA||ADAPTEC 5405 SAS RAID Controller||Yes|
BalaBit Shell Control Box (SCB) is available as a virtual appliance, as well, running under VMware ESXi server 4.0 or later.
The roles of each SCB administrator can be clearly defined using a set of privileges:
- manage SCB as a host;
- manage the connections to the servers;
- view the audit trails of certain connections
- access reports
- perform 4-eyes authorization
- and so on
SCB is configured from a clean, intuitive web interface. Access to the SCB web interface can be restricted to a physically separate network dedicated to the management traffic. This management interface is also used for backups, logging to remote servers, and other administrative traffic. Users accessing the web interface can be authenticated to an LDAP or a RADIUS database. All configuration changes are automatically logged; SCB can also require the administrators to add comments when they modify the configuration of SCB. SCB creates reports from the configuration changes, and the details and descriptions of the modifications are searchable and can be browsed from the web interface, simplifying the auditing of SCB.