Balabit 12 - Connection and channel policies

Balabit SCB Solution · Previous: Backup, archive and retention · Next: End-user access

A connection policy decides which client may connect to which port of the SCB, which jump servers the user may name, how the user authenticates, which channels of the protocol may be opened and by whom, and what happens to the recording afterwards. This part goes through the RDP and SSH connections of site 1 as chapter 7 of my design records them, the channel, authentication, content and protocol policies they reference, and the connections of site 2 as its exported configuration shows them nine months later. Why the SCB runs as a bastion host with inband destination selection, and the port plan of all partners, are in Modes of operation and connections.

One connection and what it references

A connection policy is mostly a list of references. This is PARTNER1_SSH_JumpServer with the names it points to in site 1:

flowchart LR
  conn["Connection PARTNER1_SSH_JumpServer, 10.11.16.65 and 2001:db8:a1:c0e::f:1 port 22"]
  tgt["Inband targets 10.11.17.81 and ten IPv6 /64 ranges, port 22"]
  set["SSH settings PARTNER1_SSH"]
  auth["Authentication policy base"]
  ldap["LDAP server AD.EXAMPLE.NET"]
  chan["Channel policy PARTNER1-SSH-ONLY"]
  grp["Remote group SCB_USERS_PARTNER1"]
  time["Time policy 7x24"]
  cont["Content policy no-WINSCP, site 2 only"]
  aud["Audit policy default"]
  idx["Indexer policy default"]
  bkp["Backup PARTNER1-BACKUP"]
  arc["Archive/cleanup PARTNER1-ARCHIVE"]
  conn --> tgt
  conn --> set
  conn --> auth
  conn --> ldap
  conn --> chan
  chan --> grp
  chan --> time
  chan -.-> cont
  conn --> aud
  conn --> idx
  conn --> bkp
  conn --> arc

The other six connections of the design have the same shape. Five of the references depend on the company (protocol settings, channel policy, remote group, backup, archive); the audit policy, the LDAP server policy, the indexer policy and, for SSH, the authentication policy are shared by all. The two shared policies with pages of their own are Config documents: LDAP server policy AD.EXAMPLE.NET (site 1) and Default audit policy (site 1).

The connections of site 1

Chapter 7 lists three RDP and four SSH connections. All of them listen on 10.11.16.65/32 and 2001:db8:a1:c0e::f:1/128 and differ in port, client range and targets.

The full pages are Config documents: RDP connections, site 1 and SSH connections, site 1.

Six of the seven accept any source address. The analysis had answered "the range of VPN IP addresses will be allowed" for both RDP and SSH, and the communication matrix names the VPN segments of the partners and the organisation as the sources; the connections themselves left that to the network in front of the SCB. Partner 2's connection is the exception for IPv4 and still accepts any IPv6 client. The firewall rules that enforce the VPN ranges are not in my documents.

The source address the jump server sees is the SCB's own ("use the IP address of SCB"). The analysis had asked whether the target should see the SCB, the client or a fixed address, and did not record the answer; the configuration chose the SCB. As I understand it, in non-transparent mode that is what lets the jump servers' firewalls admit administrative traffic from the SCB alone, which the design asks for.

For SSH the SCB stands in the middle with keys on both sides. Towards the client it presents its own RSA host key (a placeholder here). Towards the jump server it accepts a plain host key the first time it sees it and checks it on every later connection; X.509 host certificates are off on both sides. The RDP connections do not verify the jump server's certificate at all. All seven index their trails with the default indexer policy at normal priority, log every download of a trail, and leave the connection rate limit, credential store, usermapping and AA plugin empty.

What happens when a client connects

The introduction of the design, taken from the vendor's description, gives the rules: connection policies are compared one by one and the first that matches completely is applied; the channel policy then decides about each channel and whether it is audited. Put together for this installation, in the order as I understand it:

flowchart TB
  c["Client connects to the SCB address and a port"]
  m{"First connection policy matching source, address and port?"}
  r1["Refused"]
  t{"Target in the username on the inband list?"}
  r2["Refused"]
  a["Authentication relayed to the jump server, password or keyboard-interactive"]
  ch{"Channel type in the channel policy and user in its remote group?"}
  r3["Channel refused"]
  ct{"Content policy match, WinSCP text in a shell"}
  term["Connection terminated, logged, notified"]
  rec["Channel recorded, trail encrypted, timestamped and signed"]
  after["Indexed, backed up at night, archived after 90 days"]
  c --> m
  m -- "no" --> r1
  m -- "yes" --> t
  t -- "no" --> r2
  t -- "yes" --> a
  a --> ch
  ch -- "no" --> r3
  ch -- "yes" --> ct
  ct -- "match" --> term
  ct -- "no match" --> rec
  rec --> after

The content policy step exists only where a channel policy references it, which in site 1 was nowhere (below). Where in this sequence the SCB looks up the user's groups, and whether the RDP "pre channel check" moves the channel decision before the connection to the server, is the vendor's internals; the documents do not show it.

Channel policies

The channel policy is what ties a connection to a company. Each rule allows one channel type, for one AD role group in "remote groups", at all times (time policy 7x24), with four-eyes off and audit on. Gateway groups are empty because gateway authentication is not used. The group check goes through the LDAP server policy with nested groups, so a user in SCB_USR_PARTNER1 passes as a member of SCB_USERS_PARTNER1; the groups are in Active Directory and access control. Since six of the seven connections accept any source, this check is what keeps a partner 1 user out of the organisation's port.

The answers are in RDP and SSH channel policies, site 1.

The RDP names are misleading at first sight: a "terminal only" policy that allows the clipboard. The appliance's built-in RDP policy terminal-only allows exactly Drawing and Clipboard too (the site 2 config.xml shows its two rules), so the custom policies are the built-in one plus a group. Everything else (drive and printer redirection, sound, dynamic channels) stays closed. The analysis had said that further RDP channels would be filtered and that this would need gateway authentication; the filtering was done by listing two channels, without gateway authentication.

For SSH, the shell policies allow X11 forwarding beside the shell, and nothing else: no port forwarding, no agent forwarding, no remote command execution. The design does not say why X11 was wanted. The file transfer policies allow SCP and SFTP and log each transfer. Here chapter 7 has a slip: both SCP/SFTP connections reference PARTNER1-SSH-ONLY or ORG-SSH-ONLY, which as documented have no SCP or SFTP channel, and the documented file transfer policies are referenced by nothing. In site 2 the SCP/SFTP connections reference PARTNER1-SCP-SFTP-ONLY and ORG-SCP-SFTP-only, so I take the site 1 table for a copy error, but what site 1 really ran is not in my documents.

Authentication: relayed passwords

Every SSH connection uses the authentication policy base: no gateway authentication backend on the client side, no GSSAPI, and only password and keyboard-interactive relayed to the jump server, public key and X.509 off. The user types the password of their account on the jump server, and the SCB passes it on; nobody can use an SSH key through the SCB. The analysis had put the questions (password, key, certificate?) to the Linux platform administrator, and the document records no answer; the configuration is the answer. The RDP connections have no authentication policy field; NLA is on in the RDP settings, and the SCB is not a domain member ("join domain" disabled). The credential store, which would let users log in without knowing the target password, was "not considered for now" in the analysis and stayed empty.

The WinSCP content policy

The design explains the one content policy. WinSCP in its "SCP" mode does not run SCP as the protocol defines it; it transfers files inside a Session Shell channel. With the shell allowed, such transfers go through, do not appear among the file operations in the search, and cannot be saved from the trail. no-WINSCP therefore matches the text "WinSCP: this is end-of-file" on the screen of an SSH or Telnet session and logs, terminates and notifies. The user access guide tells WinSCP users to choose SFTP, which goes through the SFTP channel and is logged properly (End-user access).

In the site 1 design, though, the policy is defined and not used: the "content policy" field of every shell rule is empty. The site 2 config.xml references it from the shell rule of both SSH channel policies. My notes keep the vendor's warning that content policies slow connections down about five times, which may be why it was left out at first; the documents do not say. The policy and the smaller objects are in Content, indexer and user list policies, site 1.

Protocol settings and global options

The SSH settings PARTNER1_SSH and ORG_SSH are identical: the long legal banner before login, no strict mode, compression off, and algorithm lists that in December 2017 still offered diffie-hellman-group1-sha1, CBC ciphers and hmac-sha1 on both sides. The site 2 file of September 2018 offers the SCB 5 default lists in PARTNER1_SSH and ORG_SSH: group-exchange with SHA-256 first but still diffie-hellman-group-exchange-sha1 and diffie-hellman-group14-sha1, CTR ciphers and SHA-2 MACs only, and has the pre channel check on; whether site 1 was tightened the same way is not recorded. See SSH settings and authentication policy, site 1.

The three RDP settings are identical too: ten minutes idle timeout, 2000 × 2000 pixels at 32 bits, RDP 5 only, NLA on without requiring domain membership, pre channel check on, unreliable usernames refused, autologon domain suffix ad.example.net. None of the connections acts as a remote desktop gateway, although the analysis had decided that the SCB would take over the Terminal Services gateway role. See RDP settings and global options, site 1.

The global options switch SSH and RDP on and HTTP, Telnet and VNC off (ICA too, per the site 2 file); for all protocols the trails are timestamped by the SCB's local TSA and signed every 30 seconds, and for SSH and RDP the connection database is cleaned after 180 days (Backup, archive and retention). The indexer policy fixes OCR to English and two further languages. Only the built-in time policies and user lists exist, and no channel uses anything but 7x24.

Site 2 compared

The site 2 configuration of 2018-09-17 is the only connection configuration the appliance itself wrote: Connections in config.xml (site 2). Against the site 1 design:

The connection summary marks more site 2 connections as configured than the file has: partner 4's SCP/SFTP on 2213 and the cloud team's three on 2210 to 2212. They were added after September 2018 or never; the documents do not tell which.

Loose ends

• ORG_RDP_JumpServer carries NAME = PARTNER1_RDP_JumpServer in chapter 7.
• The SSH channel policies are titled in lower case (PARTNER1-ssh-only) and referenced in upper case (PARTNER1-SSH-ONLY); site 2 spells the organisation's file transfer policy ORG-SCP-SFTP-only.
• Partner 2's target 10.11.19.177 is not in the design's jump server list; the connection summary gives that address to dc1-a-vcrdp003 as a target of PARTNER3_RDP_JumpServer, whose clients come from the same 10.11.20.192/26; its partner 2 sheet is empty.
• The connections of partner 3 and of the cloud team of partner 1 exist only in the connection summary and the user access guide; no policy page of them is recorded.
• PARTNER4_RDP_JumpServer accepts any client in the config.xml and 10.12.20.0/27 in the connection summary.

Checked against One Identity Safeguard for Privileged Sessions 9.0

Per-document details are in the Config documents.

What I would do differently

• Reference the content policy from the shell channels from the first day, as site 2 did, and measure the slowdown instead of fearing it.
• Keep one set of SSH algorithms for both clusters and remove group1, CBC and hmac-sha1 in site 1 as soon as site 2 showed it worked.