Balabit 13 - End-user access

Balabit SCB Solution · Previous: Connection and channel policies · Next: Operations, upgrades and troubleshooting

Everything before this part is configuration; this is what a partner's operator actually typed. The SCB in non-transparent mode cannot be bypassed, if the network forces the traffic through it, which my documents do not show; and it cannot be guessed: a user has to know one address, one port and a user name with the target written into it, and has to put them into the right fields of a client that does not know it talks to a proxy. The end-user access guide (version 0.5 of 2018-11-05, a draft like the design) was written for that, one section per partner and site, and chapter 9 of the design has the first examples from 2017. Both are short on explanation, and both have copy-and-paste mistakes that a user copying a command would trip over.

What a user needs

Four things: a VPN connection into the organisation's network, an Active Directory account that is a member of the partner's group SCB_USR_*, a supported client, and the client settings of the guide. The account and its groups are the subject of Active Directory and access control. The VPN set-up of the partners is not in my material, and neither are the firewall rules that force traffic to the jump servers through the SCB.

The analysis had asked whether connections should be filtered by the client's address and got the answer "The range of VPN IP addresses will be allowed". As built, most connections accept any source (0.0.0.0/0 and ::/0) and leave that to the network. Partner 2's connection is the one with a range in both the design (10.11.20.192/26) and the site 2 export. In the connection summary the later partners have source ranges too: partner 3 10.11.20.192/26, the cloud team of partner 1 10.12.20.128/26 and 2001:db8:105c:fa5::/64, partner 4 10.12.20.0/27; of those, only partner 4's connection is in an exported configuration, and there it accepts any source.

The guide lists the clients that the vendor supported, with the versions tested, and does not say which ones the users really had:

How the syntax works

Every connection on the SCB is selected by the port on the production 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 uses inband destination selection: the target is not fixed in the connection but taken from the user name, and it must be one of the targets listed in the connection. For the two SSH shell connections (partner 1 and the organisation) the list is a jump server (10.11.17.81, 10.11.16.177) and ten IPv6 /64 ranges of the out-of-band jump servers in sites 1 to 5; for the others it is one or two addresses. Why this layout was chosen is in Modes of operation and connections.

The examples are the organisation's in site 1; <username> is the guide's placeholder for the user's AD account. The –p with an en dash is as printed, see the loose ends. A user's SSH session then goes like this; the policies the SCB applies on the way are those of Connection and channel policies.

sequenceDiagram
  participant u as Workstation over VPN
  participant s as SCB 10.11.16.65
  participant a as Active Directory
  participant j as Jump server dc1-a-vcjmp001
  u->>s: SSH to port 2201, user admin01@10.11.16.177
  s->>s: Port 2201 selects ORG_SSH_JumpServer, target 10.11.16.177 is in its list
  s-->>u: Banner of the SSH settings ORG_SSH
  s->>j: SSH from the SCB address to 10.11.16.177 port 22, host key accepted the first time
  u->>s: Password
  s->>j: Password relayed, authentication policy base
  j-->>s: Login accepted
  s->>a: LDAPS 636, groups of admin01
  a-->>s: Member of SCB_USERS_ORG
  s->>s: Channel policy allows session shell, audit trail is recorded
  s-->>u: Shell on the jump server

Three things in it are my reading of the configuration rather than written down anywhere. The user authenticates to the jump server, not to the SCB: the authentication policy base has no gateway authentication and relays password and keyboard-interactive. The AD lookup decides only which channels the user may open, through the "remote groups" of the channel policy. And whether the banner comes before or after the password I cannot tell from the documents.

Who reaches what

The port plan grew with every partner. Site 1 as configured and documented in the guide:

flowchart LR
  p1["Partner 1"]
  org["Organisation"]
  p3["Partner 3"]
  subgraph scb1["SCB site 1, 10.11.16.65"]
    s22["22 SSH"]
    s222["222 SCP SFTP"]
    s3389["3389 RDP"]
    s2201["2201 SSH"]
    s2202["2202 RDP"]
    s2203["2203 SCP SFTP"]
    s2205["2205 SSH"]
    s2206["2206 SCP SFTP"]
    s2207["2207 RDP"]
  end
  jmp2["dc1-a-vcjmp002 10.11.17.81"]
  oob["OOB jump servers sites 1 to 5, IPv6"]
  rdp2["dc1-a-vcrdp002 10.11.16.201"]
  scp["dc1-a-vcscp001 10.11.17.129, shared"]
  jmp1["dc1-a-vcjmp001 10.11.16.177"]
  rdp1["dc1-a-vcrdp001 10.11.16.193"]
  rdp3["dc1-a-vcrdp003 10.11.19.177"]
  p1 --> s22
  p1 --> s222
  p1 --> s3389
  org --> s2201
  org --> s2202
  org --> s2203
  p3 --> s2205
  p3 --> s2206
  p3 --> s2207
  s22 --> jmp2
  s22 --> oob
  s222 --> scp
  s3389 --> rdp2
  s2201 --> jmp1
  s2201 --> oob
  s2202 --> rdp1
  s2203 --> scp
  s2205 --> jmp1
  s2206 --> scp
  s2207 --> rdp1
  s2207 --> rdp3

Site 2, where the guide documents only the cloud team and partner 4; the connections of partner 1 and the organisation come from the connection summary and the config.xml:

flowchart LR
  p1["Partner 1"]
  org["Organisation"]
  cloud["Cloud team of partner 1"]
  p4["Partner 4"]
  subgraph scb2["SCB site 2, 10.12.16.65"]
    t22["22 SSH"]
    t222["222 SCP SFTP"]
    t3389["3389 RDP"]
    t2201["2201 SSH"]
    t2202["2202 RDP"]
    t2203["2203 SCP SFTP"]
    t2210["2210 SSH"]
    t2211["2211 SCP SFTP"]
    t2212["2212 RDP"]
    t2208["2208 RDP"]
  end
  j2["dc2-a-vcjmp002 10.12.17.81"]
  sc2["dc2-a-vcscp001 10.12.17.129"]
  r2["dc2-a-vcrdp002 10.12.16.201"]
  j1["dc2-a-vcjmp001 10.12.16.177"]
  r1["dc2-a-vcrdp001 10.12.16.193"]
  c1["dc6-a-vcojp002, site 6"]
  c2["dc6-a-vcscp002, site 6"]
  c3["dc6-a-vcrdp002, site 6"]
  r4["dc2-a-vcrdp004 10.12.19.209"]
  p1 --> t22
  p1 --> t222
  p1 --> t3389
  org --> t2201
  org --> t2202
  org --> t2203
  cloud --> t2210
  cloud --> t2211
  cloud --> t2212
  p4 --> t2208
  t22 --> j2
  t222 --> sc2
  t3389 --> r2
  t2201 --> j1
  t2202 --> r1
  t2203 --> sc2
  t2210 --> c1
  t2211 --> c2
  t2212 --> c3
  t2208 --> r4

The SSH connections of partner 1 and the organisation in site 2 have the same IPv6 ranges of the out-of-band jump servers as in site 1; I left them out of the second drawing. Partner 1 kept the standard ports 22 and 3389, so its users can leave the clients' default ports; every later connection got a port from 2201 up. Partner 3 has two Windows jump servers behind one port, 2207, told apart only by the address in the user name. Every value of the guide, per partner, site and client, is in the Config document End-user client settings; the full connection summary is in Connection summary.

Not every partner is in the guide. Partner 2 has an RDP connection on port 2204 in the site 1 design and in the site 2 config.xml (to 10.11.19.177 and 10.12.19.177), but no section in the guide and an empty sheet in the summary. In site 1 that connection accepts the same source range as partner 3's connections and leads to the same jump server as partner 3's second RDP target, dc1-a-vcrdp003; the documents do not explain the overlap. Partner 4's SCP connection on port 2213 is only in the summary. Partner 5 is named in the guide's audience and has a test account, but no connection anywhere.

Files: SFTP, upload and the home directory

All WinSCP examples set the file protocol to SFTP. That is not a preference: WinSCP in SCP mode moves files inside a shell channel, the SCB would not list them as file operations, and in site 2 the content policy no-WINSCP terminates such sessions; in the site 1 design it is defined but not referenced. Partner 1 has to use the directory upload on the file server; for partner 3 and the organisation the scp examples copy into /home/<username>. Either way the home directory on the file server is mounted on the Linux jump servers under /home/<username>/data/, so a file copied in through the SCB can be used on the jump server; on the Windows jump servers the guide says "Not yet implemented".

The syntax in my test notes

My notes keep three test strings, undated, written in a form that differs from the guide's:

The current SPS 9.0 administration guide documents username%targetserver@scb_address as an alternative to the @ form; as I understand it, the % form exists for clients that do not accept @ in a user name field; that ^ separates the target's port in the RDP form is my reading of the pattern in the notes. The RDP test carries the AD domain in front of the user name, which the guide's MSTSC examples leave out. Where @localhost pointed to the notes do not say. The test accounts in the notes and the groups they were in:

The two lists disagree for the first two accounts. My reading is that test_scb1 and test_scb2 started as administrator and operator test accounts of the web interface and were later reused for the cloud team and partner 4; the notes do not date either list.

Loose ends

• The guide was written in Word, which turned the hyphen of -p and -P into an en dash – in every command that has a port option. Copied from the guide, ssh and scp take –p for a host or file name and fail.
• The cloud team's OpenSSH command reads ssh –P 2210. Even with a hyphen that is wrong: ssh takes the port as -p; -P is the port option of scp only.
• The cloud team's scp command "to platform" has partner 1's site 1 target and SCB, <username>@10.11.17.129@10.11.16.65, with the site 2 port 2211; the "from platform" line next to it is right.
• The cloud team's SSH jump server is 10.19.17.98 in the guide and 10.19.17.96 in the summary. Which one was configured I cannot tell: the site 2 config.xml of September 2018 has no cloud connection yet.
• The guide files the cloud team under "Location – Site 2". That is the SCB they connect to, 10.12.16.65; their jump servers are in site 6 (dc6-a-…, 10.19.17.x).
• In the summary, the organisation's SSH connection in site 2 has IPv4 port 2210 and IPv6 port 2201; 2210 is the cloud team's SSH port. The site 2 config.xml has 2201.
• The design's scp examples have no port for partner 1, so they reach port 22, the SSH connection, and –P 2201 for the organisation, also the SSH connection. As I read the documented channel policies of those connections, they allow a shell and X11 but no SCP. The tables of the same examples give the targets 10.11.17.81 and 10.11.16.177, the commands 10.11.17.129. The guide fixed all four.
• The design's DNS table puts scb.example.net on the production address, and every example in both documents uses it that way; the administrators' hosts file in Operations, upgrades and troubleshooting maps it to the management address.

Checked against One Identity Safeguard for Privileged Sessions 9.0

From the release notes I infer, without having tested it, that a current OpenSSH client with its default settings would offer none of the two key exchange algorithms that the site 1 connections accepted from clients, and could not connect without adding one by hand. The users' clients of 2018 were older.