Balabit 03 - Modes of operation and connections

Balabit SCB Solution · Previous: Logical design and integrations · Next: Hardware, cabling and networks

The SCB can be put into a network in several ways, and the choice decides what users type into their clients, what the firewall has to do and how the configuration grows when a new partner arrives. This installation used the bastion-host mode, let users name their target inside the username, and gave every partner and protocol its own port on one address. This part explains those three decisions, the role of IPv6, the port plan of both sites as it stood in 2018, and how the policies of one connection hang together.

Non-transparent mode

In transparent mode the SCB stands in the path of the traffic like a router or a bridge, and the clients address the servers as if it were not there. In non-transparent mode, the one chosen here, it is a bastion host: the users address the SCB, and the SCB opens the connection to the server. The design gives the reasons: only the controlled management traffic reaches the box, and the services on the servers stay reachable if the SCB breaks down, so it cannot become a single point of failure for production. The analysis asked the question the other way round ("are these considerations correct?") and the answer was a plain yes.

The price is that the network must make sure nobody goes around the SCB. The design says it in one sentence: the firewall has to be configured so that only connections originating from the SCB can reach the servers. Those firewall rules are not in the Source material. Neither are the rules that limit who may reach which port of the SCB; on the SCB itself almost every connection accepts any source (0.0.0.0/0 and ::/0), so that filtering was left to the network and the VPNs, which the analysis had already said for RDP and SSH: "The range of VPN IP addresses will be allowed." The flows the design asked to be opened, user ports included, are in the Config document Communication matrix.

Inband destination selection

With one connection policy per target, every new jump server would have needed a new connection. Inband destination selection avoids that: the user puts the target into the username, the SCB extracts it, checks it against the list of permitted targets of the connection, and connects. The vendor's figure in the design shows what each side sees:

sequenceDiagram
  participant c as Client in Subnet 1
  participant s as SCB, interface EXTERNAL
  participant t as Server in Subnet 2 or 1
  c->>s: user uid@server port, destination SCB IP and port
  s->>t: user uid, destination server IP and port

The design writes the general form as ssh username@targetserver:port@scb_address. In practice the clients used the shorter form without the target port, because each connection has a default port for its targets: in PuTTY the host name <username>@10.11.17.81@10.11.16.65 with port 22, in WinSCP the user name <username>@10.11.17.129 with host 10.11.16.65 and port 222, in MSTSC the computer 10.11.16.65:2202 and the user name <username>@10.11.16.193. My notes also hold tests with other separators, % before the target and ^ before the RDP port; the client settings for every partner are in End-user access.

The permitted targets are what keeps inband destination selection from becoming an open proxy. Every connection in chapter 7 has a list "TARGETS - DOMAIN (PORT)" and no exceptions, and, as I understand the product, refuses a target outside it. For the RDP and SCP connections the list has one or two servers; for the SSH connections it has the jump server in the management LAN plus ten IPv6 /64 ranges, one per site and datacenter, so that a whole out-of-band network of jump servers could be named without listing them. The analysis left SFTP with "????" as an open question; in the end SFTP worked through the same mechanism, and the user access guide tells every user to choose SFTP in WinSCP.

IPv6 for users only

The SCB supports IPv6 only for the connections it monitors, not for its own services, and the design used it exactly there. Each cluster's user interface has one IPv4 and one IPv6 address (10.11.16.65 and 2001:db8:a1:c0e::f:1 in site 1, 10.12.16.65 and 2001:db8:a2:c0e::f:1 in site 2), and every connection listens on both. The reason is the out-of-band jump servers: outside the site, they are reachable only over the organisation's backbone, which is IPv6. The SCB can translate between the families, so a user on an IPv4 VPN reaches an IPv6 jump server without noticing. Management, syslog, mail, the directory and the storage stay IPv4, and the design notes that syslog could not use IPv6 on the SCB anyway.

Organising connections by port

As I understand it, in non-transparent mode the SCB has to know which connection a new session belongs to before it has seen the username. The design names the two ways: a different port of one address per connection, or a different alias address per connection. This installation used ports. An earlier network variant had a second, NAT-ed user network with its own address (it survives in the first certificate request, see Hardware, cabling and networks); the final design has one user address per site.

The documents do not say why ports won. As I understand it, the reasoning is in the structure of the policies: a connection is selected by source, destination address and port, and the connection is where the per-partner things hang (the channel policy with the partner's AD group, the backup and archive policies). With almost every source allowed, the port is the only thing that tells one partner's connection from another's, and one address meant one DNS name, scb.example.net, and one row per port in the firewall. The default ports went to partner 1 (22, 3389), the first user (FR14), and everyone else got a port from 2201 upwards.

The port plan

This is the plan as the design, the connection summary (version 7) and the user access guide (version 0.5 of November 2018) give it, checked against the site 2 config.xml of September 2018. The full summary is the Config document Connection summary.

YES, NO and NA are the values of the summary's columns "configured in DC1" and "configured in DC2"; as I read the sheet, NA marks a connection that does not belong to that site. Port 2204 is not in the summary at all; its row comes from chapter 7 and the config.xml. Jump server names without a site prefix exist in both sites (dc1-a-… with 10.11.x, dc2-a-… with 10.12.x). "Summary only" means that the config.xml of September 2018 does not have the connection; the cloud team's access was added to the user access guide in November 2018, so these connections were probably configured after the export. Port 2209 is used nowhere in the material. Partner 5 has a test account in my notes and an empty sheet in the summary, and no connection.

Site 1 as a picture. The "From" networks are those of chapter 7 and the summary; where a connection accepts any source, the arrow shows who was given that port, not a filter.

flowchart LR
  p1["Partner 1 users"]
  org["ORG users"]
  r3["10.11.20.192/26, partner 2, later partner 3"]
  c22["10.11.16.65:22 PARTNER1_SSH"]
  c222["10.11.16.65:222 PARTNER1_SCP_SFTP"]
  c3389["10.11.16.65:3389 PARTNER1_RDP"]
  c2201["10.11.16.65:2201 ORG_SSH"]
  c2202["10.11.16.65:2202 ORG_RDP"]
  c2203["10.11.16.65:2203 ORG_SCP_SFTP"]
  c2204["10.11.16.65:2204 PARTNER2_RDP"]
  c2205["10.11.16.65:2205 PARTNER3_SSH"]
  c2206["10.11.16.65:2206 PARTNER3_SCP_SFTP"]
  c2207["10.11.16.65:2207 PARTNER3_RDP"]
  jmp2["dc1-a-vcjmp002 10.11.17.81"]
  jmp1["dc1-a-vcjmp001 10.11.16.177"]
  rdp2["dc1-a-vcrdp002 10.11.16.201"]
  rdp1["dc1-a-vcrdp001 10.11.16.193"]
  rdp3["dc1-a-vcrdp003 10.11.19.177"]
  scp["dc1-a-vcscp001 10.11.17.129"]
  o94["OOB jump servers, f94 ranges, sites 1 to 5"]
  o95["OOB jump servers, f95 ranges, sites 1 to 5"]
  p1 --> c22
  p1 --> c222
  p1 --> c3389
  org --> c2201
  org --> c2202
  org --> c2203
  r3 --> c2204
  r3 --> c2205
  r3 --> c2206
  r3 --> c2207
  c22 --> jmp2
  c22 --> o94
  c222 --> scp
  c3389 --> rdp2
  c2201 --> jmp1
  c2201 --> o95
  c2202 --> rdp1
  c2203 --> scp
  c2204 --> rdp3
  c2205 --> jmp1
  c2206 --> scp
  c2207 --> rdp1
  c2207 --> rdp3

Site 2, from the config.xml and the summary; the dashed lines are connections that are in the summary only.

flowchart LR
  p1["Partner 1 users"]
  org["ORG users"]
  p2["10.19.204.192/26, partner 2"]
  p4["Partner 4 users"]
  cl["Cloud team, 10.12.20.128/26"]
  c22["10.12.16.65:22, 222, 3389 PARTNER1"]
  c2201["10.12.16.65:2201 to 2203 ORG"]
  c2204["10.12.16.65:2204 PARTNER2_RDP"]
  c2208["10.12.16.65:2208 PARTNER4_RDP"]
  c2213["10.12.16.65:2213 PARTNER4_SCP_SFTP"]
  c2210["10.12.16.65:2210 to 2212 CLOUD_PARTNER1"]
  j1["dc2-a-vcjmp002, vcrdp002, vcscp001"]
  o94["OOB jump servers, f94 ranges"]
  j2["dc2-a-vcjmp001, vcrdp001, vcscp001"]
  o95["OOB jump servers, f95 ranges"]
  r177["10.12.19.177"]
  r4["dc2-a-vcrdp004 10.12.19.209"]
  s4["dc2-a-vcscp001 10.12.17.129"]
  d6["dc6-a-vcojp002, vcscp002, vcrdp002, site 6"]
  p1 --> c22
  org --> c2201
  p2 --> c2204
  p4 --> c2208
  p4 -.-> c2213
  cl -.-> c2210
  c22 --> j1
  c22 --> o94
  c2201 --> j2
  c2201 --> o95
  c2204 --> r177
  c2208 --> r4
  c2213 -.-> s4
  c2210 -.-> d6

Some targets are shared on purpose. The SCP/SFTP file server vcscp001 serves every company; the user's home directory there is mounted on the Linux jump servers, so files travel through the SCB once, recorded, and are then available on the jump server. Partner 3 shares the organisation's SSH and RDP jump servers in site 1 and comes from the same network that the design gave to partner 2, whose RDP target 10.11.19.177 also became partner 3's second RDP jump server. The documents do not say whether partner 3 replaced partner 2.

How the policies hang together

The vendor's figure of the policies, as it is in the design:

flowchart LR
  conn["Connection policy, selected on source, target and port"]
  chan["Channel policy"]
  cont["Content policy"]
  time["Time policy"]
  aud["Audit policy"]
  auth["Authentication policy"]
  ldap["LDAP policy"]
  um["Usermapping policy"]
  arch["Archiving policy"]
  bkp["Backup policy"]
  conn --> chan
  chan --> cont
  chan --> time
  conn --> aud
  conn --> auth
  conn --> ldap
  conn --> um
  conn --> arch
  conn --> bkp

In site 1, chapter 7 fills it in like this for the seven connections of the design.

The rest is the same for all seven: audit policy default, LDAP server policy AD.EXAMPLE.NET, indexing on with the default indexer policy, no usermapping, no credential store, no gateway authentication, audit trail downloads logged, and for SSH the authentication policy base (password and keyboard-interactive relayed to the server). The source address the server sees is the SCB's own ("use the IP address of SCB"). SSH host keys of the servers are accepted the first time and checked afterwards; RDP server certificates are not verified.

The piece that ties a connection to a company is the channel policy. Each of them allows its channels (a shell and X11 forwarding for SSH; drawing and clipboard for RDP; SCP and SFTP in the file transfer policies) only for one AD role group in "REMOTE GROUPS": SCB_USERS_PARTNER1, SCB_USERS_ORG, SCB_USERS_PARTNER2. Since the connections accept any source address, this group check, resolved through the LDAP server policy, is as I understand it what stops a partner 1 user who knows port 2201 from using the organisation's jump servers. Each channel is audited, so every allowed session ends up in an audit trail encrypted and signed by the default audit policy (Audit trails: encryption and replay), and each partner's trails go to that partner's own export on the storage, which keeps one partner's recordings apart from another's when they are copied off the box (Backup, archive and retention). The policies themselves are in Connection and channel policies.

Loose ends

• The SCP/SFTP connections of chapter 7 reference PARTNER1-SSH-ONLY and ORG-SSH-ONLY, while the documented SSH policies are titled PARTNER1-ssh-only and ORG-ssh-only and allow only a shell and X11, no SCP or SFTP. The file transfer policies PARTNER1-scp-sftp-only and ORG-scp-sftp-only exist but no connection in chapter 7 uses them. In the site 2 config.xml the SCP/SFTP connections reference PARTNER1-SCP-SFTP-ONLY and ORG-SCP-SFTP-only, which is what makes sense; I take chapter 7 to be a copy-and-paste slip, but I cannot prove what site 1 really had.
• The table of ORG_RDP_JumpServer in chapter 7 carries the name PARTNER1_RDP_JumpServer; port 2202, target and policies are the organisation's.
• The connection summary gives the site 2 ORG_SSH_JumpServer IPv4 port 2210 and IPv6 port 2201. One connection has one list of ports for both families, and the config.xml has 2201; 2210 is the cloud team's SSH port and, as I read it, a typing error in the sheet.
• The cloud team's SSH jump server is 10.19.17.96 in the summary and 10.19.17.98 in the user access guide. The guide places the cloud team's access under "Location – Site 2"; the jump servers are in site 6 and only the SCB is in site 2.
• PARTNER4_RDP_JumpServer accepts 10.12.20.0/27 in the summary and any source in the config.xml, which also adds an IPv6 target, 2001:db8:a2:b5d::a:1, that the summary lacks. The site 2 PARTNER2_RDP_JumpServer accepts 10.19.204.192/26, where site 1 has 10.11.20.192/26.
• The analysis expected the SCB to take over the role of a Terminal Services gateway; every RDP connection has "act as a remote desktop gateway" set to No.

Checked against One Identity Safeguard for Privileged Sessions 9.0

What I would do differently

As built, the only thing on the SCB that kept one company's users off another company's port was the AD group of the user name that the jump server accepted; the source address was open on most connections, and the network filtering is not in my material. The vendor's checklist, then and now, says exactly what that rests on is not to be trusted. I would make the users authenticate to the SCB itself, with inband gateway authentication, so that the analysis' wish "the operator directly uses the SSH, RDP client and nothing more" still holds, and I would give every connection the source network of its partner's VPN, as the design already did for partner 2 and the summary for partners 3, 4 and the cloud team.