Balabit 01 - Requirements and concept

Balabit SCB Solution · Next: Logical design and integrations

The organisation let several partner companies administer parts of its infrastructure, and the access of all these people had to be controlled and recorded somewhere they could not reach themselves. The tool chosen was a Balabit Shell Control Box (SCB) 5 LTS: an appliance that sits between the administrators and the servers, terminates their SSH and RDP sessions, records everything into audit trails and lets only the allowed channels through. This first part covers what the box is, the questions that were asked before the design was written, the requirements and constraints the design set, the users and their roles, and the conceptual picture that everything else in this Solution fills in. My sources are the design document of the site 1 cluster (version 0.5 of 2017-12-01, still marked as a draft), the pre-design analysis that came before it, and my working notes.

What the SCB is

The SCB inspects traffic on the application layer. It speaks SSH (with forwarded X11), SCP, SFTP, RDP, HTTP, Citrix ICA, Telnet, VMware Horizon View and VNC, and simply forwards everything else. For the protocols it knows it acts as a man in the middle: the connection is cut into two halves, client to SCB and SCB to server, both are decrypted, and nothing passes directly from one side to the other. What passes is written into audit trails, which the SCB can encrypt, timestamp and sign, so that an administrator who has root on the target still cannot touch the record of what he did there. The trails can be replayed like a film, and an indexer (with OCR for graphical sessions) makes the text that appeared on the screen searchable.

What may pass is decided by policies. A connection policy is selected by the source, the destination address and the destination port; it then references the other policies: a channel policy (which channels, for example a shell, SCP, or drawing and clipboard in RDP, and for whom), an audit policy, an authentication policy, an LDAP policy, backup and archive policies, and optionally a usermapping policy. The SCB compares the connection policies in their order and applies the first one that matches. How these hang together in this installation is in Modes of operation and connections.

The design document gives the reason for the box in one sentence that I still find the best summary: administration is done over encrypted protocols, so it is hard to audit, and if the logs are kept on the administered system, a skilled administrator or an attacker can manipulate them. The SCB moves the record to a separate layer that the administrators do not control.

Before the design: the analysis

Before I wrote the design I went through a list of questions with the architect, the security architect, the Windows and Linux administrators and the logging engineer. The answers decided most of what follows.

Two notes in the analysis matter later. The first is about granularity: the SCB can apply policies per target server, but if the target is a jump server, it only sees the connection to the jump server, not what the user does from there. The second is about the source address that the target server sees (the SCB's, the client's or a fixed one); the analysis asked the question and left it unanswered, and the built connections use the SCB's own address.

The last row turned out to be the most temporary. In the design, partner 2's users already appear, and the user access guide of November 2018 has connections for partner 1, the cloud team of partner 1, partner 3, the organisation and partner 4; the connection summary has empty sheets for partners 2 and 5.

Requirements

The design lists fifteen functional requirements, two non-functional ones, four constraints and one assumption.

The constraints are the limits the product and the environment set, and the only assumption is about licences.

Read against the rest of the design, three of these do not hold as written. FR9 says all certificates come from the internal CA, and C3, in the constraints table, says the opposite for all but the IPMI certificates; C3 is what was built, and Certificates and keys tells why. FR4 lists eight protocols, while chapter 7 of the design disables HTTP, Telnet and VNC and configures only SSH and RDP connections; the requirement describes what the product can do rather than what was needed. And C2 is a constraint the design accepted knowingly: every user connection ends on a jump server, and the SCB records the session there, not the hop from the jump server onwards. NR1 cannot be checked. The second assumption, A2, is an empty row.

C1 had a practical consequence that is easy to miss: without bonding, each logical network sits on one physical port, and resilience has to come from the HA pair, not from the links. My early TODO list, in notes headed "BALABIT notes - 4.0.7.a", still has "teaming/bonding" and "configure the prod interface (in HA mode/team/bond)" on it; the answer was C1. The ports and cabling are in Hardware, cabling and networks, the pair in High availability.

Users and roles

The design divides the people twice: by the company they work for and by what they do with the SCB.

Across the companies run three roles, and each role maps to one kind of AD role group.

Administrators and operators exist only on the organisation's side (SCB_ADM_ORG, SCB_OPS_ORG); every company gets its own group of users. Two local accounts stay as exceptions: admin as the last resort for the web interface when Active Directory does not answer, and root for the console. The groups, their nesting and the access control page are in Active Directory and access control.

flowchart LR
  adm["Administrators, SCB_ADM"]
  ops["Operators, SCB_OPS"]
  usr["Users, SCB_USERS_ORG, _PARTNER1, _PARTNER2, _GUESTS"]
  loc["Local admin, emergency only"]
  root["Local root"]
  web["SCB web interface, HTTPS on 10.11.16.81"]
  con["SCB console, SSH on 10.11.16.81"]
  pro["SCB user address 10.11.16.65, SSH, RDP, SCP, SFTP"]
  jmp["Jump servers"]
  tgt["Target servers and devices"]
  adm -- "read and write, all pages" --> web
  ops -- "read, all pages" --> web
  loc -- "if AD fails" --> web
  root --> con
  usr --> pro
  pro -- "per partner connection" --> jmp
  jmp -- "outside the SCB's view" --> tgt

Later, more companies came. The test accounts in my notes cover groups for partner 1, its cloud team, the organisation, partner 3, partner 4 and partner 5 (SCB_USR_CLOUD_PARTNER1, SCB_USR_PARTNER3, SCB_USR_PARTNER4, SCB_USR_PARTNER5), none of which is in the design. Who these partners are beyond "a partner company" the documents do not say, and it does not matter for the design: each new partner meant its own connections and its own AD group, and in the material that shows it, its own backup and archive policies.

The conceptual design

The concept is short. The SCB is the single entry point for management access in the management LAN of site 1. A user connects to the SCB, the SCB connects him to a jump server, and from the jump server he reaches the production infrastructure. Jump servers are grouped by protocol (SSH, RDP, SCP/SFTP), by placement (in the management LAN or in an out-of-band network), by company (the organisation's, partner 1's, or shared) and by site. The out-of-band jump servers outside site 1 are reached over the organisation's backbone. Active Directory holds the users and groups, and the NetApp stores the backups and archives.

The conceptual figure of the design, redrawn:

flowchart LR
  p1u["PARTNER1 VPN USERS"]
  adu["admin VPN USERS"]
  subgraph s1["Site 1 - management LAN"]
    scb["Balabit SCB"]
    ds["Directory Services"]
    nas["Network Attached Storage"]
    pi["Production Infrastructure"]
    subgraph orgj["ORG_JUMP_SERVERS"]
      ordp["RDP_JUMP_SERVER"]
      ossh["SSH_JUMP_SERVER"]
    end
    subgraph p1j["PARTNER1_JUMP_SERVERS"]
      prs["RDP+SSH_JUMP_SERVER"]
    end
    subgraph shj["SHARED_JUMP_SERVERS"]
      scp["SCP_JUMP_SERVER"]
    end
  end
  bb["ORG BACKBONE"]
  oob1["Site 1 - OOB"]
  oob2["Site 2 - OOB"]
  oob4["Site 4 - OOB"]
  oobx["Remote Location X - OOB"]
  p1u -- "SSH, RDP, SCP, SFTP" --> scb
  adu -- "SSH, RDP, SCP, SFTP" --> scb
  scb -- "RDP" --> ordp
  scb -- "SSH" --> ossh
  scb -- "SSH" --> prs
  scb -- "RDP" --> prs
  scb -- "SCP, SFTP" --> scp
  scb -- "LDAPS" --> ds
  scb -- "CIFS" --> nas
  scb --> oob1
  scb -.-> bb
  bb -.-> oob2
  bb -.-> oob4
  bb -.-> oobx

Each out-of-band box in the original holds a group of partner 1 jump servers, a group of the organisation's jump servers and its own production infrastructure; I left the groups out to keep the picture readable. The production infrastructure in site 1 has no line in the original either: nothing in the concept connects to it except through a jump server.

The line to the storage says CIFS. That was the plan in December 2017, and it did not survive: the backup over SMB failed and the exports became NFS, as told in SVMs and NFS of the NetApp Solution. The backup and archive tables of the same design document already say NFS, so the figure and the text of the concept are older than the tables.

Loose ends

• The design is version 0.5, a draft, yet its chapter 7 is titled as the configuration "from real implementation realized in production environment". Wherever the concept and chapter 7 disagree in this Solution, I take chapter 7 as the as-built and say so.
• The analysis expected partner 2's users to bypass the SCB; the design gives them a connection, an AD group and backup and archive policies. The connection summary of 2018 has an empty sheet for partner 2, so I cannot tell whether that connection was ever used.
• The firewall rules on the network side, which in non-transparent mode are what forces administrators through the SCB, are not in the Source material. Neither is the set-up of the partners' VPNs.
• Four-eyes authorisation, the credential store and gateway authentication were discussed in the analysis and not used. The analysis contradicts itself on the last one: it does not want gateway authentication, but wants further RDP channels filtered, which by its own note needs it.

Checked against One Identity Safeguard for Privileged Sessions 9.0

Everything in this build is out of support. One Identity announced the acquisition of Balabit on 2018-01-17, within weeks of the design; the product is now One Identity Safeguard for Privileged Sessions (SPS); the newest documents are those of SPS 9.0, of September 2026. The individual settings are compared in the Articles and Config documents that hold them; this is the summary for the concept.

The architecture is the same in substance: a boot firmware that provides HA and starts the core firmware, a master/slave pair (now called primary and secondary) with DRBD, a redundant heartbeat and next-hop monitoring, and most of the policies of this design under the same names; user lists are announced for removal. What would change most in a rebuild today is the hardware and the path to it, not the concept.