Search

EP-4742592-A1 - SSH METHOD AND PROXY FOR APPLICATION-LEVEL POLICY CONTROL

EP4742592A1EP 4742592 A1EP4742592 A1EP 4742592A1EP-4742592-A1

Abstract

A method and a device comprising the steps of: processing incoming SSH connections in a Downstream Proxy unit; involving a Policy Engine unit to control user access and access to the SSH server; opening an outgoing SSH connection from an Upstream Proxy unit to the SSH server; transferring SSH channel data between the SSH client, Downstream Proxy unit, Policy Engine unit, Upstream Proxy unit and SSH server in both directions; allowing the Policy Engine unit to filter the transferred data with definable policy control whether chunks of data can already be forwarded while more data is still being received or whether more data needs to be received before deciding on data forwarding, and controlling window sizes of the SSH protocol between the SSH client and the Downstream Proxy unit and/or between the Upstream Proxy unit and the SSH server independently from each other and autonomously sending window size adjust messages, allowing to receive and to provide more data to the Policy Engine unit without stalling the connection, hereby enabling the Policy Engine unit to make decisions to forward, hold or block any amount of data based on the definable policy control, wherein the window size defines the amount of SSH channel data exchanged before receiving and/or sending a window size adjustment message.

Inventors

  • STECHER, MARTIN

Assignees

  • Cloud Fellows GmbH

Dates

Publication Date
20260513
Application Date
20241112

Claims (15)

  1. A method comprising the steps of: processing incoming SSH connections in a Downstream Proxy unit; involving a Policy Engine unit to control user access and access to the SSH server; opening an outgoing SSH connection from an Upstream Proxy unit to the SSH server; transferring SSH channel data between the SSH client, Downstream Proxy unit, Policy Engine unit, Upstream Proxy unit and SSH server in both directions; allowing the Policy Engine unit to filter the transferred data with definable policy control whether chunks of data can already be forwarded while more data is still being received or whether more data needs to be received before deciding on data forwarding, and controlling window sizes of the SSH protocol between the SSH client and the Downstream Proxy unit and/or between the Upstream Proxy unit and the SSH server independently from each other and autonomously sending window size adjust messages, allowing to receive and to provide more data to the Policy Engine unit without stalling the connection, hereby enabling the Policy Engine unit to make decisions to forward, hold or block any amount of data based on the definable policy control, wherein the window size defines the amount of SSH channel data exchanged before receiving and/or sending a window size adjustment message.
  2. The method of claim 1 where the transferred SSH data is interpreted on an application protocol level, preferably SCP, SFTP or Git, and where the Downstream Proxy unit exchanges application protocol level control messages with the SSH client and/or the Upstream Proxy unit exchanges application protocol level control messages with the SSH server, both autonomously and independently from messages from the other side, preferably a direct SSH_FXP_STATUS message in response to a SSH_FXP_WRITE message from the SSH client, in order to avoid the problem of stalling connections on an application protocol level while waiting for a policy decision before data can be forwarded.
  3. The method of claim 1 or 2, wherein the Policy Engine unit is responsible for one or more different decisions during an SSH connection: - for decisions whether a user of the SSH client application is allowed to connect to the SSH server, - for decisions on whether to allow a channel request of a specific type and/or command preferably an SCP upload and/or download, an SFTP session, a shell session and/or a Git repository clone - for decisions on allowing, blocking or modifying data exchanged on such a channel, preferably an SFTP upload and/or download, by analyzing the channel data as a stream of data chunks including the option to hold data as long as needed before a decision is made.
  4. The method of any of the claims 1 to 3, wherein the Policy Engine unit maintains Connection Context, Transaction Context and/or Meta Connection Context information across the SSH connection and/or for multiple parallel and/or historic SSH connections, allowing the definable policy to continuously interact with that information for policy decisions, hereby allowing to refer to context and intermediate results determined at previous policy transactions.
  5. The method of any of the claims 1 to 4 of where the Downstream Proxy unit and/or the Upstream Proxy unit are implemented as application-level proxy tasks and/or the Policy Engine unit is implemented as a Policy Engine task, all with independent task scheduling and incoming message queues and preferably wherein the tasks are linked to each other with a dual-linked chain of tasks, enabling an asynchronous execution of the tasks, and preferably one Application-level Proxy task embodiment is parsing and generating messages of the SFTP protocol; one Application-level Proxy task embodiment is parsing and generating messages of the SCP protocol; one Application-level Proxy task embodiment is parsing and generating messages of the Git protocol, and/or additional Application-level Proxy tasks to be added for other SSH application-level protocols.
  6. The method of any of the claims 4 to 5 of where the Application-level Proxy task on the Downstream Proxy unit side of the task chain is forming a virtual shell emulating the server responses to keyboard input of the user, and the Application-level Proxy task at the Upstream Proxy unit side is forming a virtual terminal client emulating the keyboard input of the user, together allowing to map commands and responses of an SSH shell session into higher-level abstracted messages for the Policy Engine unit.
  7. The method of any of the claims 1 to 6, wherein the Application-level messages of the SSH application protocol are abstracted into higher-level messages that are protocol-agnostic to unify similar functionality of different application-level protocols for the Policy Engine unit, allowing policy to execute a single policy routine for multiple SSH applications, preferably s a single routine for file transfers via SCP, SFTP or Git.
  8. The method of any of the claims 1 to 7 wherein an additional Policy Multiplexer task in the task chain triggers multiple Policy Engine unit transactions in parallel in order to support multiplexing application-level protocols such as the parallel transfer of multiple files via SFTP and thereby decoupling the pausing and/or resuming of the parallel data transfers.
  9. The methods of any of the claims 4 to 8 wherein the Policy Engine unit modifies data in the Transaction Context resulting in altered data content in the SSH application-level protocol to support modification of the commands, responses and files exchanged between SSH client and SSH server thru the SSH Proxy.
  10. The methods of claim 1 and claim 3 wherein the Policy Engine unit generates block events, resulting in block messages flowing in the opposite direction thru the dual-linked task chain and error messages generated in the application-level protocol in order to provide end users with proper error messages and to support blocking of only some files while allowing other files in the data transfer of a set of files, preferably such as the download and/or upload of a directory.
  11. The method of any of the claims 1 to 10 wherein the hostname for the SSH server is determined by the Policy Engine unit from information made available thru the Connection Context by mapping that information to a list of hostnames, or by programmatically calculating the hostname from information encoded into the username.
  12. The method of any of the claims 1 to 11 wherein the hostname for the SSH server is retrieved after the SSH client connects to the Downstream Proxy unit as being a jump host and exposing the SSH server name to the jump host; the Downstream Proxy unit retaining the SSH server host name in the Connection Context of the Policy Engine unit; the Downstream Proxy connecting to a second Virtual Downstream Proxy unit; the Virtual Downstream Proxy unit connecting to the same Policy Engine unit and to the Upstream Proxy unit, and the Upstream Proxy unit connecting to the SSH server available in the Connection Context.
  13. The method of any of the claims 1 to 12 wherein the Upstream Proxy unit authenticates the user for the upstream connection with public key encryption by using public/private key pairs provided by the Policy Engine unit from local storage or retrieved remotely, or by opening an SSH Agent channel to the SSH client, requesting a list of available public keys from the client, selecting the keys to be used in upstream authentication by the Policy Engine unit and asking the SSH client through the SSH Agent channel to sign the response for the user authentication challenge.
  14. The method of any of the claims 1 to 13 wherein the Policy engine unit executes the definable policy by one or more of the following: running a Python interpreter to execute a customer policy written in Python; interconnecting to a 3 rd -party policy engine; implementing an ICAP client and translating triggered policy transactions to pseudo HTTP-transactions to interact with generic ICAP servers; implementing an OCP client in combination with an OCP scheme for SSH and translating triggered policy transactions to match that OCP scheme, or implementing a HTTP(S)-REST client and translating triggered policy transactions to REST calls to interact with generic REST APIs.
  15. A device comprising a central processing unit, network interfaces and a memory, wherein in the memory a program is stored and executed to implement a method according the method claims 1 to 14.

Description

TECHNICAL FIELD This disclosure relates in general to the field of information security, and more particularly, to a proxy server and a method for SSH-based application-level protocols under the control of a multi-layer policy engine unit. BACKGROUND OF THE INVENTION The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. It is built across multiple layers defined within IETF originally in RFCs 4250-4256 and several later RFCs and Internet Drafts to extend the original specifications. As the name indicates, the initial usage of SSH is to provide shell access to a remote computer in a secure way but the original RFCs already define how to leverage the secure network protocol to run various remote commands and subsystems on top of the core SSH protocol. These SSH-enabled applications include SCP and SFTP (defined in Internet Draft draft-ietf-secsh-filexfer) for file transfer, the git command to communicate from a client computer via SSH with a GitHub server working with source code repositories and various other applications. In most deployments, clients and servers are using an SSH implementation like OpenSSH (often part of the computer's operating system) which launches new SSH child processes per connection. On the client, either the ssh application is called directly by a user or a program or one of the applications (like "scp" or "git") are started on the client that launch ssh as sub-process. On the server side, the ssh process either starts a new terminal session or launches the corresponding server-side application thru a command (like scp or git-upload-pack) or thru a subsystem (like sftp-server). The communication between the SSH process and the SSH application process is then typically via stdin/stdout/stderr pipes or could also be implemented using Unix domain sockets. Image 1 shows the standard implementation stack for SSH applications. In this context, the term application-level protocol is used to describe the specification of the data format used on top of the SSH core protocol. For example, the SFTP protocol in the draft-ietf-secsh-filexfer Internet Draft series defines a packet format and packet types like SSH _FXP_INIT and these SFTP packets are sent as payload of an SSH_MSG_CHANNEL_DATA message (as defined in RFC 4254). The SFTP protocol and all other protocols specified to run as payload on SSH_MSG_CHANNEL_DATA messages are referred to as "application-level protocols". SSH connections can be sent via other intermediate computers either by using the intermediate as a jump host (available as an integrated option in most standard SSH programs) or by using the intermediate as an SSH proxy server. SSH proxy server products are often implemented as part of advanced Firewall solutions. Proxy server solutions acting as a trusted main-in-the-middle for encrypted connections are also known for Web applications using SSL/TLS. The Proxy server establishes separate secure connections between the client and the proxy and between the proxy and server and then decodes, filters and re-encodes the data sent thru the secure proxy connections. These SSL/TLS proxies are used within Secure Web Gateway products for example. Solutions in the Security Service Edge (SSE) market connect powerful and feature-rich policy engine units for access control and content filtering to secure web gateways, to email intermediates, to cloud application APIs and other policy enforcement points. Access control can be based on any combination of network and connection properties (like server names, IP addresses, port numbers, client and server locations), user properties (user names, group memberships, user location, user scoring and behavior), device posture, functionality and commands being executed or requested) and many more. Content filtering can be based on analysis of the payload data being transferred (such as a transferred file, transferred shell command or response, etc.) and analyzed with available filter engines such as for Anti-Malware or data protection or any generic policy decision such as matching against regular expressions, dictionaries or any other rule-based policy decision). The capabilities of the filter engine benefit from the transaction context built across different layers of the network and data flows. For policy triggers in context of a Secure Web Gateway, one design goal is to start looking at data and provide a verdict as early as possible, another design goal is to handle data in chunks and provide them to the policy engine unit as a stream of data, potentially forwarding parts of the data to the other proxy side and provide the filter engine with a "need more data" decision to interrupt policy execution and to resume when new data arrives. These goals help to lower the latency and provide a better end-user experience. Another goal of an SSE solution would be to unify policy such that a single customer policy definition c