Evaluating the Balabit Shell Control Box

February 23, 2017


Table of Contents

1. Evaluating Balabit Shell Control Box in a virtual environment
1.1. Downloading the evaluation version of SCB
2. Setting up SCB and the virtual environment
2.1. Deploying SCB in a virtual machine
2.2. Creating a simple scenario
3. General connection settings
3.1. Modes of operation
3.2. Configuring the destination selection method
3.3. Network settings
4. Configuring connections - SSH
4.1. Configuring a basic SSH connection
4.2. Fix destination selection
4.3. Inband destination selection
4.4. Configuring an advanced channel policy for SSH
4.5. Group-based auditing
4.6. Integration with ticketing systems
5. Configuring connections - RDP
5.1. Configuring a basic RDP connection
5.2. Fix destination selection
5.3. Inband destination selection
6. Enabling SCB to act as a HTTP proxy
7. Real-time content monitoring with Content Policies
7.1. Creating a new content policy
8. Indexing service
8.1. Using the content search
8.2. Configuring the internal indexer

1. Evaluating Balabit Shell Control Box in a virtual environment

[1]To evaluate SCB as a virtual appliance, you can download and install the latest SCB ISO file into a virtual machine. The following virtual environments are supported for evaluation: Microsoft Hyper-V, VMware, and vSphere (VMware ESX). SCB may work in other virtual environments like VirtualBox or KVM as well, although these are officially not supported. You can obtain an evaluation license and the ISO file using your MyBalaBit account.

Before you start: 

Before you start evaluating SCB, make sure you understand what SCB is and how it works. This information can greatly help you get SCB operational. Read the following:

1.1. Procedure – Downloading the evaluation version of SCB

  1. Login to your MyBalaBit account and request access to the evaluation version of SCB. If you do not have an account, sign up for a new account. Please note that new accounts are not immediately available. You will receive an e-mail when your account is activated. Similarly, you will receive an e-mail when you can access the SCB evaluation license and the ISO image.

  2. Visit the SCB download page and download the ISO image (install cdrom) of the latest SCB version.

    Download the latest Feature release ("F"), or the latest LTS release if there is no newer Feature release available. For details on the differences between the latest Feature and LTS versions, see the related What is new in Balabit Shell Control Box guide, or contact your Balabit representative.

  3. Download the SCB license. Evaluation licenses are valid for a month.



[1] All questions, comments or inquiries should be directed to or by post to the following address: Balabit SA 1117 Budapest, Alíz Str. 2 Phone: +36 1 398 6700 Fax: +36 1 208 ­0875 Web: https://www.balabit.com/

Copyright © 2017 Balabit SA All rights reserved. This document is protected by copyright and is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Balabit.

All trademarks and product names mentioned herein are the trademarks of their respective owners.

2. Setting up SCB and the virtual environment

2.1. Deploying SCB in a virtual machine

See the following procedures to install SCB in a virtual machine.

2.1.1. Procedure – Setting up Balabit Shell Control Box with vSphere

  1. Download the vSphere application.

    Visit the vSphere webpage, and download latest version of the application for your operating system.

  2. Install the vSphere application.

    Follow the instructions provided in the vSphere product documentation to install the application.

  3. Install SCB. Follow the instructions provided in Appendix E, Balabit Shell Control Box VMware Installation Guide in The Balabit Shell Control Box 4 F4 Installation Guide.

  4. Configure a simple scenario and evaluate SCB. For details, see Procedure 2.2, Creating a simple scenario.

2.1.2. Procedure – Setting up Balabit Shell Control Box with VirtualBox

  1. Download the VirtualBox application

    Download the latest version of VirtualBox for your operating system.

  2. Install the VirtualBox application.

    • On Microsoft Windows, start the VirtualBox.exe file.

    • On Linux systems, follow the instructions provided in the VirtualBox manual.

  3. Install SCB. Follow the instructions provided in Appendix E, Balabit Shell Control Box VMware Installation Guide in The Balabit Shell Control Box 4 F4 Installation Guide.

  4. Configure a simple scenario and evaluate SCB. For details, see Procedure 2.2, Creating a simple scenario.

2.1.3. Procedure – Setting up Balabit Shell Control Box with Hyper-V

  1. Download the Hyper-V application.

    Visit the Hyper-V webpage, and download latest version of the application for your operating system.

  2. Install the Hyper-V application.

    Follow the instructions provided in the Hyper-V product documentation to install the application.

  3. Install SCB. Follow the instructions provided in Appendix F, Balabit Shell Control Box Hyper-V Installation Guide in The Balabit Shell Control Box 4 F4 Installation Guide.

  4. Configure a simple scenario and evaluate SCB. For details, see Procedure 2.2, Creating a simple scenario.

2.1.4. Procedure – Setting up Balabit Shell Control Box using Kernel-based Virtual Machine (KVM)

  1. Install a virtual machine manager application

    Install a KVM manager application, for example, virt-manager.

  2. Install SCB. Follow the instructions provided in Appendix G, Installing Balabit Shell Control Box as a Kernel-based Virtual Machine in The Balabit Shell Control Box 4 F4 Installation Guide.

  3. Configure a simple scenario and evaluate SCB. For details, see Procedure 2.2, Creating a simple scenario.

2.2. Procedure – Creating a simple scenario

  1. Connect to SCB.

    The SCB virtual machine acquires an IP address from your DHCP server accessible in the virtual environment. After SCB has booted up, the console displays the IP address of the SCB web interface at login prompt. To connect to SCB, use this IP address. For details, or tips if SCB cannot receive an IP address, see Section 3.1, The initial connection to SCB in The Balabit Shell Control Box 4 F4 Administrator Guide.

  2. Complete the Welcome Wizard as described in Procedure 3.2, Configuring SCB with the Welcome Wizard in The Balabit Shell Control Box 4 F4 Administrator Guide. Upload the evaluation license file you have downloaded with your MyBalabit account.

  3. Configure a server: set up a host that is on the same subnet as SCB, and enable Remote Desktop (RDP) or Secure Shell (SSH) access to it.

  4. Configure a connection on SCB to forward the incoming RDP or Secure Shell (SSH) connection to the host and establish a connection to the host. See Procedure 3.3, Logging in to SCB and configuring the first connection in The Balabit Shell Control Box 4 F4 Administrator Guide for details.

  5. Replay your session in the browser. See Procedure 16.1.2, Replaying audit trails in your browser in The Balabit Shell Control Box 4 F4 Administrator Guide for details.

    In case you have questions about SCB, or need assistance, contact your Balabit representative.

3. General connection settings

SCB supports transparent and non-transparent proxy operation modes to make deployments in existing network infrastructures as easy as possible. SCB will automatically handle non-transparent and transparent connections simultaneously.

For details, see Modes of operation.

3.1. Modes of operation

The following operation modes are possible:

3.1.1. Non-transparent proxy operation

This guide focuses on non-transparent proxy operation, which is the easiest to implement. In this configuration, clients connect to a server through SCB. That is, end-users address SCB explicitly, which then forwards connections to target systems based on various parameters depending on what destination selection method you select.

SCB in non-transparent mode

Figure 1. SCB in non-transparent mode


For an illustration of what happens when a client connects a server through SCB and how the different configuration options and policies of SCB affect this process, see:

3.2. Configuring the destination selection method

To configure the destination selection method, navigate to for example SSH Control > Connections (or the respective protocol control that you want to configure), and in the Target section, select the preferred method:

  • Use the original target address of the client: Connect to the IP address targeted by the client. This is the default behavior in transparent mode.

  • NAT destination address: Perform a network address translation on the target address.

  • Use fix address: The connection will connect always to this address, redirecting the clients to the server.

  • Inband destination selection: Extract the address of the server from the username.

For details, see Modifying the destination address.

3.3. Network settings

3.3.1. Assigning logical interfaces to physical interfaces

To assign logical interfaces to the three physical interfaces of SCB, navigate to Basic Settings > Network > Interfaces.

Each logical interface must have its own VLAN ID, and can have its own set of (alias) IP addresses and prefixes. The configured name for each logical interface is visible on SCB's user interface only.

You can configure IPv4 and IPv6 addresses as well. IPv6 is intended for configuring monitored connections, local services (including the web login) require IPv4 addresses. An interface can have multiple IP addresses, including a mix of IPv4 and IPv6 addresses.

For details, see Network settings.

3.3.2. Routing uncontrolled traffic

To control how SCB routes uncontrolled traffic (that is, traffic that passes SCB but is not inspected or audited) between its network interfaces, navigate to Basic Settings > Network > IP forwarding.

You can connect interface pairs to each other, and SCB will route all uncontrolled traffic between these. To add a new forwarding rule, choose and select the two logical interfaces to connect. You can select the same interface in both fields to use that logical interface in single-interface router mode.

For details, see Routing uncontrolled traffic between logical interfaces.

4. Configuring connections - SSH

The following procedures will provide a skeleton of configuring SSH connections in SCB. If you want to have a deeper understanding, see the in-depth detailed procedure in Configuring connections.

4.1. Procedure – Configuring a basic SSH connection

Purpose: 

To configure a basic SSH connection in SCB, complete the following steps:

Steps: 

  1. To configure a Secure Shell connection, navigate to SSH Control > Connections.

  2. Click to define a new connection and enter a name that will identify the connection (for example admin_mainserver).

    Tip

    It is recommended to use descriptive names that give information about the connection, for example refer to the name of the accessible server, the allowed clients, and so on.

  3. Enter the IP address of the client that will be permitted to access the server into the From field. Click to list additional clients.

  4. Enter the IP address that the clients will request into the To field.

  5. If the clients use a custom port to address the server instead of the default port used by the protocol, enter the port number that the clients will request into the Port field. Click to list additional port numbers.

  6. Non-transparent mode: Enter the IP address and port number of the target server into the Target field. SCB will connect all incoming client-side connections to this server. For details on organizing connections in non-transparent mode, see Organizing connections in non-transparent mode.

  7. Click to save the connection.

    Tip

    To temporarily disable a connection, deselect the checkbox before the name of the connection.

4.2. Fix destination selection

Fix address selection is used to expect connections on an IP address of SCB using the default SSH port 22 and to forward it to a server explicitly set in the corresponding destination field.

For more information about creating connections, see Configuring connections in The Balabit Shell Control Box Administrator Guide.

4.2.1. Procedure – Configuring fix destination selection

Purpose: 

The destination address is the address of the server where the clients finally connect to. To modify the destination address of a connection, complete the following steps.

Steps: 

  1. Navigate to SSH Control > Connections and click to display the details of the connection.

    Configuring fix destination selection

    Figure 2. Configuring fix destination selection


  2. The Target section allows you to configure Network Address Translation (NAT) on the server side of SCB. Destination NAT determines the target IP address of the server-side connection. Set the destination address as required.

    Note

    It is not possible to direct the traffic to the IP addresses belonging to SCB.

  3. Select Use fix address.

  4. Enter the IP address and port number of the server. The connection will connect always to this address, redirecting the clients to the server.

    You can also enter a hostname instead of the IP address, and SCB automatically resolves the hostname to IP address. Note the following limitations:

    • SCB uses the Domain Name Servers set Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.

    • Only IPv4 addresses are supported.

    • If the Domain Name Server returns multiple IP addresses, SCB selects randomly from the list.

  5. Click .

4.2.2. Server-side (only) password authentication

The default authentication method for SSH connection policies is to let the target system check credentials as it would happen when users access the server directly without SCB in place.

If you want to configure a different authentication method, create an authentication policy.

Authentication policy

Figure 3. Authentication policy


An authentication policy is a list of authentication methods that can be used in a connection. Connection definitions refer to an authentication policy to determine how the client can authenticate to the target server. Separate authentication methods can be used on the client and the server-side of the connection.

To create a new authentication policy, navigate to SSH Control > Authentication Policies.

For details, see Authentication Policies.

4.2.3. Permitting or denying access to SSH channels

For certain protocols, multiple channels are defined each of which is responsible for a specific functionality supported by the protocol. For example, the Session Shell channel is the traditional remote terminal session, while the Session Exec channel allows to execute a remote command (for example rsync without opening a session shell.

For details on the supported SSH channel types, see Supported SSH channel types.

SCB can permit/deny access to these functionalities based on various parameters of a connection (for example time of the day, username, and so on) to provide an additional level of access control and protection.

Controlling protocol channels

Figure 4. Controlling protocol channels


Access to sub-channels is controlled by channel policies. The default SSH channel policy allows session shell access only.

For details, see Creating and editing channel policies.

4.2.3.1. Procedure – Configuring SCP and SFTP access in SSH

Steps: 

  1. Navigate to SSH Control > Channel Policies and click to create a new channel policy. Enter a name for the policy into the Channel Policy field (for example, shell_and_backup).

  2. Click to add a new channel.

  3. Select Session Exec SCP from the Type field.

  4. Restrict the availability of the channel based on your preferences.

    For details, see Creating and editing channel policies.

  5. To be able to extract the original file from the corresponding audit trail for further inspection, select the Audit option to record the activities of the channel into audit trails.

  6. Optional step: To also configure SFTP channel access, add a new channel and repeat the steps above, but this time, select Session SFTP from the Type field.

4.2.4. Authorizing and monitoring a connection personally in real-time

This is called four-eyes authorization in SCB terminology. When four-eyes authorization is required for a connection, a user (called authorizer) must authorize the connection on SCB as well. This authorization is in addition to any authentication or group membership requirements needed for the user to access the remote server. Any connection can use four-eyes authorization, so it provides a protocol-independent, outband authorization and monitoring method.

The authorizer has the possibility to terminate the connection any time, and also to monitor real-time the events of the authorized connections: SCB can stream the traffic to the Audit Player application, where the authorizer (or a separate auditor) can watch exactly what the user does on the server, just like watching a movie.

Four-eyes authorization

Figure 5. Four-eyes authorization


For details on four-eyes authorization, see Four-eyes authorization.

4.2.4.1. Procedure – Configuring four-eyes authorization

Steps: 

  1. To enforce four-eyes authorization, navigate to SSH Control > Connections.

  2. Select the connection policy to modify. Navigate to Access Control and click .

  3. Enter the name of the usergroup whose members are permitted to authorize the sessions of the connection policy into the Authorizer field.

  4. Configure the parameters of four-eyes authorization. For details, see Configuring 4-eyes authorization.

  5. Navigate to SSH Control > Channel Policies, and select the channel policy used in the connection.

  6. Enable the 4 eyes option for the channels which should be accessed only using four-eyes authorization.

  7. Click .

4.3. Inband destination selection

Using fix destination selection has the disadvantage of requiring one connection policy per protected server, because policies are mapped to servers based on IP addresses or port numbers.

Inband destination selection allows you to create a single connection policy and allow end-users to access any server. by including the name of the target server in their username (for example ssh username@targetserver:port@scb_address). SCB can extract the address from the username and direct the connection to the target server.

Inband destination selection

Figure 6. Inband destination selection


The process looks like the following:

  1. End-users specify the destination server as part of the username, for example in the format of <username>@<server address>:<port>@<SCB address>, where the server and SCB address can be either a hostname or an IP address.

  2. SCB tokenizes the username and the server address to forward the connection to.

  3. SCB forwards the connection to the server.

For details, see Using inband destination selection in SSH connections.

4.3.1. Procedure – Configuring inband destination selection

Purpose: 

To configure a Connection Policy to extract the address of the server from the username, complete the following steps.

Steps: 

  1. Navigate to the Connection policy you want to modify, for example, to SSH Control > Connections.

  2. Select Inband destination selection.

    Configuring inband destination selection

    Figure 7. Configuring inband destination selection


  3. Enter the addresses of the servers that the users are permitted to access into the Targets field.

  4. If the clients can access only a specified port on the server, enter it into the Port field. If the Port is not set, the clients may access any port on the server.

  5. If there are any servers that the users cannot target using inband destination selection, add them to the Exceptions field.

  6. Click .

    Example 1. Initiating a connection

    Once the connection policy is configured correctly, a sample connection initiation would look like the following:

    $ ssh root@192.168.56.10@192.168.56.200
    • root = server user

    • 192.168.56.10 = target server

    • 192.168.56.200 = IP address of SCB

4.3.2. Server-side (only) password authentication

The default authentication method for SSH connection policies is to let the target system check credentials as it would happen when users access the server directly without SCB in place.

If you want to configure a different authentication method, create an authentication policy.

Authentication policy

Figure 8. Authentication policy


An authentication policy is a list of authentication methods that can be used in a connection. Connection definitions refer to an authentication policy to determine how the client can authenticate to the target server. Separate authentication methods can be used on the client and the server-side of the connection.

To create a new authentication policy, navigate to SSH Control > Authentication Policies.

For details, see Authentication Policies.

4.3.3. Gateway authentication

When gateway authentication is required for a connection, the user must authenticate on SCB as well. This additional authentication can be performed on the SCB web interface, so it provides a protocol-independent, outband authentication method. That 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. Also, connections using general usernames (for example root, Administrator, and so on) can be connected to real user accounts.

Gateway authentication

Figure 9. Gateway authentication


For details on gateway authentication, see The gateway authentication process.

4.3.3.1. Procedure – Password-based gateway (local) + password-based server-side authentication from credential store:

Purpose: 

The goal of this scenario is to demonstrate an SSH connection in which end-users must authenticate themselves successfully with their own passwords against a local user database maintained on SCB and have a session opened to the requested destination with a different account without any further interaction (that is, have SCB complete the password-based login process).

Steps: 

  1. Create a local user database: 

    Navigate to Policies > Local User Databases and create a local user database.

    For details, see Creating a Local User Database.

  2. Connect the local user database with a client-side gateway authentication policy: 

    Navigate to SSH Control > Authentication Policies. Create an authentication policy. Select Client-side gateway authentication backend > Local. Select Password. Configure the required settings.

    For details, see Local client-side authentication.

  3. Create a user list: 

    Navigate to Policies > User lists and create a user list.

    For details, see Creating and editing user lists.

  4. Create a usermapping policy: 

    Navigate to Policies > Usermapping policies and create a usermapping policy.

    For details, see Configuring usermapping policies.

  5. Create a local or remote credential store with the server user and its password. SCB provides a plugin framework to integrate with other remote credential stores/password management systems too.

    For details, see Using a custom Credential Store plugin to authenticate on the target hosts.

  6. Expected outcome:

    If all prerequisites are met, SCB is ready to perform inband gateway authentication in an SSH session, which together with inband destination selection could be performed with the following connection string by an end-user:

    Example 2. Inband gateway authentication and destination selection
    $ ssh gu=balabit@root@192.168.56.10@192.168.56.200
    • gu=balabit = gateway user (balabit)

    • root = server user

    • 192.168.56.10 = target server

    • 192.168.56.200 = IP address of SCB

4.3.3.2. Procedure – Public key-based gateway + password-based server-side authentication from credential store:

Purpose: 

This scenario differs from the previous one only in the client-side authentication method. In this case, the end-user is authenticated with the public key method, and if all permissions are granted by SCB (for example usermapping is allowed), they get logged in automatically to the requested server with the requested server account without having to enter a password.

To configure this, upload a public key for the user in the applied local user database, and make sure that the private key is accessible for the client application (openSSH, PuTTY, and so on).

Steps: 

  1. Create a local user database: 

    Navigate to Policies > Local User Databases and create a local user database.

    For details, see Creating a Local User Database.

  2. Connect the local user database with a client-side gateway authentication policy: 

    Navigate to SSH Control > Authentication Policies. Create an authentication policy. Select Client-side gateway authentication backend > Local. Select Public key. Configure the required settings.

    For details, see Local client-side authentication.

  3. Create a user list: 

    Navigate to Policies > User lists and create a user list.

    For details, see Creating and editing user lists.

  4. Create a usermapping policy: 

    Navigate to Policies > Usermapping policies and create a usermapping policy.

    For details, see Configuring usermapping policies.

  5. Create a local or remote credential store with the server user and its password. SCB provides a plugin framework to integrate with other remote credential stores/password management systems too.

    For details, see Using a custom Credential Store plugin to authenticate on the target hosts.

  6. Expected outcome:

    If all prerequisites are met, SCB is ready to perform inband gateway authentication in an SSH session, which together with inband destination selection could be performed with the following connection string by an end-user:

    Example 3. Inband gateway authentication and destination selection
    $ ssh gu=balabit@root@192.168.56.10@192.168.56.200
    • gu=balabit = gateway user (balabit)

    • root = server user

    • 192.168.56.10 = target server

    • 192.168.56.200 = IP address of SCB

4.4. Procedure – Configuring an advanced channel policy for SSH

Purpose: 

The channel policy lists the channels (for example, terminal session and SCP in SSH) that can be used in the connection, and also determines if the channel is audited or not. The Channel policy can also restrict access to each channel based on the IP address of the client or the server, a user list, user group, or a time policy. For example, all clients may access the servers defined in a connection through SSH terminal, but the channel policy may restrict SCP access only to a single client. The rules defined in the channel policy are checked when the user attempts to open a particular channel type in the connection.

The order of the rules matters. The first matching rule will be applied to the connection. Also, note that you can add the same channel type more than once, to fine-tune the policy. This can be helpful in the following cases:

  • Four eyes authorization is required only for certain target user groups (Administrator/root)

  • Group-based auditing: only certain user groups are audited

  • Remote access to a certain server is only allowed during non-business hours for example to ensure that work is not interrupted because of system maintenance.

Based on the environment of the customer, such requirements could probably also be solved by creating multiple channel policies, hence having multiple-connection policies in place. But because connection policies are selected by only matching IP addresses and destination ports, especially group-based decisions cannot be solved at this stage. The third example can definitely be solved by a separate connection policy having a special channel policy assigned. But if this is the only difference to another connection policy, solving the issue by an additional rule in the channel policy is much faster and keeps a clean ruleset.

For details, see Creating and editing channel policies.

Steps: 

  1. Navigate to SSH Control > Channel Policies and click to create a new channel policy. Enter a name for the policy.

  2. Click to add a new channel.

  3. Select the channel to be enabled in the connection from the Type field.

  4. To restrict the availability of the channel only to certain clients, click in the From field and enter the IP address of the client allowed to use this type of the channel.

  5. To restrict the availability of the channel only to certain servers, click in the Target field and enter the IP address of the server allowed to use this type of the channel.

  6. To restrict the availability of the channel when using gateway authentication, click in the Gateway Group field and enter the name of the user group allowed to use this type of the channel.

  7. To restrict the availability of the channel only to certain users, click in the Remote Group field and enter the name of the user group allowed to use this type of the channel.

  8. Select a Time policy to narrow the availability of the channel.

  9. Decide which actions to trigger if the parameters configured above match: 

    Select the 4 eyes option to require four-eyes authorization to access the channel.

    Select the Audit option to record the activities of the channel into audit trails.

  10. Click .

4.5. Group-based auditing

It is sometimes a requirement to record connections of certain users only. If those uses cannot be identified by layer 3/4 connection parameters, this issue is not solved by creating separate connection policies with each having assigned a specific channel policy with auditing enabled/disabled.

To solve this issue, configure the group(s) that are affected by the channel settings:

Group-based auditing

Figure 10. Group-based auditing


In this scenario, only users of gateway groups gr_supplier-A and gr_supplier-C are audited when requesting a new SSH session shell channel. If these two groups are not matched, the second rule matches and no recording is triggered. Without the second rule, users that do not match the specified groups would be denied by this channel policy.

4.6. Integration with ticketing systems

SCB provides a plugin framework to integrate SCB to external ticketing (or issue tracking) systems, allowing you to request a ticket ID from the user before authenticating on the target server. That way, SCB can verify that the user has a valid reason to access the server — and optionally terminate the connection if they do not.

Currently the following protocols are supported: 

  • Remote Desktop (RDP)

  • Secure Shell (SSH)

  • Telnet

  • TN3270

The following is an example of a gateway authentication process with ticketing integration in PuTTY

Authentication with ticketing integration in PuTTY

Figure 11. Authentication with ticketing integration in PuTTY


For details, see Integrating ticketing systems.

5. Configuring connections - RDP

The following procedures will provide a skeleton of configuring RDP connections in SCB. If you want to have a deeper understanding, see the in-depth detailed procedure in Configuring connections.

5.1. Procedure – Configuring a basic RDP connection

Purpose: 

To configure a basic RDP connection in SCB, complete the following steps:

Steps: 

  1. To configure a Remote Desktop connection, navigate to RDP Control > Connections.

  2. Click to define a new connection and enter a name that will identify the connection (for example admin_rdpserver).

    Tip

    It is recommended to use descriptive names that give information about the connection, for example refer to the name of the accessible server, the allowed clients, and so on.

  3. Enter the IP address of the client that will be permitted to access the server into the From field. Click to list additional clients.

  4. Enter the IP address that the clients will request into the To field.

  5. If the clients use a custom port to address the server instead of the default port used by the protocol, enter the port number that the clients will request into the Port field. Click to list additional port numbers.

  6. Non-transparent mode: Enter the IP address and port number of the target server into the Target field. SCB will connect all incoming client-side connections to this server. For details on organizing connections in non-transparent mode, see Organizing connections in non-transparent mode.

  7. Click to save the connection.

    Tip

    To temporarily disable a connection, deselect the checkbox before the name of the connection.

5.2. Fix destination selection

Fix address selection is used to expect connections on an IP address of SCB using the default RDP port 3389 and to forward it to a server explicitly defined in the corresponding destination field.

For more information about creating connections, see Configuring connections in The Balabit Shell Control Box Administrator Guide.

5.2.1. Procedure – Configuring fix destination selection

Purpose: 

The destination address is the address of the server where the clients finally connect to. To modify the destination address of a connection, complete the following steps.

Steps: 

  1. Navigate to RDP Control > Connections and click to display the details of the connection.

    Configuring fix destination selection

    Figure 12. Configuring fix destination selection


  2. The Target section allows you to configure Network Address Translation (NAT) on the server side of SCB. Destination NAT determines the target IP address of the server-side connection. Set the destination address as required.

    Note

    It is not possible to direct the traffic to the IP addresses belonging to SCB.

  3. Select Use fix address.

  4. Enter the IP address and port number of the server. The connection will connect always to this address, redirecting the clients to the server.

    You can also enter a hostname instead of the IP address, and SCB automatically resolves the hostname to IP address. Note the following limitations:

    • SCB uses the Domain Name Servers set Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.

    • Only IPv4 addresses are supported.

    • If the Domain Name Server returns multiple IP addresses, SCB selects randomly from the list.

  5. Click .

5.3. Inband destination selection

Non-transparent operation with inband destination selection in RDP is supported with the implementation of the Terminal Services Gateway protocol. When it is enabled, end-users configure their Mstsc client to use SCB as an RDP proxy/gateway and keep specifying target server addresses on the General tab the way they are used to.

Inband destination selection with RDP

Figure 13. Inband destination selection with RDP


5.3.1. Procedure – Configuring inband destination selection

Purpose: 

To configure a Connection Policy to extract the address of the server from the username, complete the following steps.

Steps: 

  1. Navigate to the Connection policy you want to modify, for example, to RDP Control > Connections.

  2. Select Inband destination selection.

    Configuring inband destination selection

    Figure 14. Configuring inband destination selection


  3. Enter the addresses of the servers that the users are permitted to access into the Targets field.

  4. If the clients can access only a specified port on the server, enter it into the Port field. If the Port is not set, the clients may access any port on the server.

  5. If there are any servers that the users cannot target using inband destination selection, add them to the Exceptions field.

  6. To use inband destination selection with RDP connections without using SCB as a Terminal Services Gateway, you must use SSL-encrypted RDP connections.

    For details, see Using SSL-encrypted RDP connections.

  7. Click .

6. Procedure – Enabling SCB to act as a HTTP proxy

Purpose: 

To enable SCB to act as a HTTP proxy, perform the following steps.

Steps: 

  1. Navigate to HTTP Control > Connections and configure the connection.

  2. Enable Act as HTTP proxy.

    For details, see Enabling SCB to act as a HTTP proxy.

  3. Enable SSL encryption in the HTTP connection policy configuration. In SSL Settings, select Permit HTTPS traffic.

    For details, see Enabling SSL encryption in HTTP.

  4. Based on the configuration of the client-side certificate handling, you have to import either an X.509 server certificate and private key or a signing CA.

    For details, see Signing certificates on-the-fly.

  5. On the server side, certificate checking is optional. When enabled, configure a Trusted CA list policy and apply it to the connection policy.

    For details, see Verifying certificates with Certificate Authorities.

  6. Expected results:

    Act as a dedicated HTTPS proxy

    Figure 15. Act as a dedicated HTTPS proxy


7. Real-time content monitoring with Content Policies

You can monitor the traffic of certain connections in real time, and execute various actions if a certain pattern (for example, a particular command or text) appears in the command line or on the screen, or if a window with a particular title appears in a graphical protocol. Since content-monitoring is performed real-time, SCB can prevent harmful commands 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. In case of ICA, RDP, and VNC connections, SCB can detect window title content.

The following channels support content policies:

  • SSH Session shell (event type: Commands/Screen Content/Credit card)

  • Telnet (event type: Commands/Screen Content/Credit card)

  • RDP Drawing (event type: Window title detection)

  • VNC (event type: Window title detection)

  • ICA Drawing (event type: Window title detection)

For details, see Real-time content monitoring with Content Policies.

7.1. Procedure – Creating a new content policy

Purpose: 

To create a new content policy that performs an action if a predefined content appears in a connection, complete the following steps.

For details, see Creating a new content policy.

Steps: 

  1. Navigate to Policies > Content Policies, click and enter a name for the policy.

  2. Select the Event type that you want to monitor.

  3. Select Match, click and enter a string or regular expression. SCB will perform an action if this expression is found in the connection, unless it is listed in the Ignore list.

  4. To add an exception to the Match rule, select Ignore, click and enter a string or regular expression.

  5. Select the action to perform.

  6. Click .

  7. To use the content policy created in the previous steps, select the policy in the channel policy that is used to control the connections.

8. Indexing service

Since version 4 LTS, SCB introduces an internal indexer service replacing and improving the functionality of the external Audit Player Indexing service. The external indexing service is still available and can be used with SCB, but not in combination with the internal one. Compared to the Audit Player Indexing service, the new on-box indexer also supports non-latin character recognition and offers significantly improved search capabilities.

For details, see Indexing audit trails.

8.1. Using the content search

To most effectively search in the contents of the audit trails, make sure that the following prerequisites are met:

  • Indexing was enabled in the connection policy related to the audit trail during the session, and

  • the audit trail has already been indexed.

For details, see Using the content search.

8.2. Procedure – Configuring the internal indexer

Purpose: 

SCB can index the contents of audit trails using its own indexer service or external indexers. Indexing extracts the text from the audit trails and segments it to tokens. A token is a segment of the text that does not contain whitespace: for example words, dates (2009-03-14), MAC or IP addresses, and so on. The indexer returns the extracted tokens to SCB, which builds a comprehensive index from the tokens of the processed audit trails.

Once indexed, the contents of the audit trails can be searched from the web interface. SCB can extract the commands typed and the texts seen by the user in terminal sessions, and text from graphical protocols like RDP, Citrix ICA, and VNC. Window titles are also detected.

For details, see Configuring the internal indexer.

Steps: 

  1. Navigate to Basic Settings > Local Services > Indexer service, and select Indexer service.

  2. Define the Maximum parallel audit trails to index on box. The default value is set to the number of detected CPU cores.

  3. Optional step: f you have encrypted audit trails and you want to index them, upload the necessary RSA keys (in PEM-encoded X.509 certificates).

  4. Click .

  5. Navigate to Policies > Indexer Policies.

  6. To create a new Indexer Policy, click .

  7. To configure what languages to detect, select Manual language selection. Select the language(s) to detect.

  8. Navigate to the Control page of the traffic type (for example SSH Control), and select the connection policy to index.

  9. Select Enable indexing.

  10. To determine the priority level of indexing this connection, select the appropriate Priority level.

  11. Select the Indexing Policy to be used.

  12. Click .

  13. Check which channel policy is used in the connection, and navigate to the Connection policies page.

  14. Select the channel policy used in the connection to index, and verify that the Audit option is selected for the channels you want to index (for example, the Session shell channel in SSH, or the Drawing channel in RDP).

  15. Click .