Transparent bastion

Abstract

The present technology relates to providing secure access to a protected service through an intermediary agent that operates as a transparent proxy. The agent, which may be implemented using a bastion server, an extended Berkeley Packet Filter (eBPF) mechanism, or a combination of both, mediates communication between a client device and a service endpoint running on a host. The client presents a certificate signed by a certificate authority (CA), including user-specific metadata, policy directives, and session duration constraints. Upon receipt, the agent authenticates the certificate and establishes a secure session with the client using a secure access protocol such as SSH, RDP, or VNC. The agent enforces access policies, including session timespan, command restrictions, and user permissions. Communication between the agent and the protected service is encrypted using ephemeral keys generated by the agent, and isolation techniques ensure that only the agent can access the service endpoint.

Description

Docket No. 873003 (1065366 / WO / SEC / l)TRANSPARENT BASTIONBACKGROUND

[0001] A bastion host (also referred to as a bastion jump server) is a specifically configured system used to securely bridge external networks and internal resources by exposing a minimal set of hardened services to untrusted environments. Positioned, for example, outside of a firewall or in a demilitarized zone (DMZ), the host can run applications such as SSII or RDP access proxies, with unrelated software disabled or removed to reduce the attack surface. The bastion host can be configured to withstand high-bandwidth attacks and undergo heightened security practices, such as hardening, auditing, and monitoring (e.g., due to its position as a critical access gateway).

[0002] In some examples, the bastion host can be placed either between two firewalls within a DMZ or outside a single firewall, depending on network architecture complexity and resource availability. Despite variation in placement, the core function remains consistent: mediating and controlling traffic between external clients and internal services.

[0003] Use cases for bastion hosts extend beyond providing secure remote shell access. The bastion host can operate as an authentication gateway, enforcing strong identity checks before allowing entry. The bastion host can serve as an alternative to VPNs by reducing network-wide exposure and permitting fine-grained access control. In some configurations, the bastion host can act as proxy points for internal administration tools, file transfers, or credentialsharing workflows. Bastion hosts may also host software inventory management tools or support intrusion detection mechanisms by centrally monitoring and logging activity.BRIEF DESCRIPTION OF THE SEVERAE VIEWS OF THE DRAWINGS

[0004] In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0005] FIG. 1A illustrates a block diagram of a first example of a system using a signed certification for secure communications in accordance with some embodiments of the present technology.Docket No. 873003 (1065366 / WO / SEC / l)

[0006] FIGS. IB- IE illustrate block diagrams of respective systems for providing a protected service in accordance with some embodiments of the present technology.

[0007] FIG. 2 illustrates an example flow diagram of a method for providing a protected service in accordance with some embodiments of the present technology.

[0008] FIG. 3A illustrates an example of a block diagram of an extended Berkley packet filter (eBPF), in accordance with some embodiments of the present technology.

[0009] FIG. 3B illustrates an example of a block diagram of an eBPF map in an eBPF, in accordance with some embodiments of the present technology.

[0010] FIG. 3C illustrates a block diagram of an example of implementing Linus security module (LSM) hooks and Linus security module extended Berkley packet filter programs (LSM BPF), in accordance with some embodiments of the present technology.

[0011] FIG. 4 illustrates a block diagram of an example of a data processing unit (DPU) in accordance with some embodiments of the present technology.

[0012] FIG. 5 illustrates a block diagram of an example of a network having an access cluster in the access layer in accordance with some embodiments of the present technology.

[0013] FIG. 6 illustrates a block diagram of an example of a subsystem of a network that includes data processing units (DPUs) that perform various network component functions, in accordance with some embodiments.

[0014] FIG. 7 illustrates a block diagram of an example of a computing device that can be used to implement one or more parts of the present technology.DESCRIPTION OF EXAMPLE EMBODIMENTS

[0015] Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.OVERVIEW

[0016] Aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applied to each aspect alone or in combination with other features.

[0017] In some aspects, the techniques described herein relate to a method for providing a secure service, the method including: providing a service on a service endpoint running on a host; receiving, at the host, a certificate signed by a certificate authority (CA) and sent to theDocket No. 873003 (1065366 / WO / SEC / l)host from a client device; receiving, at the host, a CA public key from the CA; interposing an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; and establishing a secure access protocol between the agent and the client device.

[0018] In some aspects, the techniques described herein relate to a method, further including: communicating between the agent and the client device using the secure access protocol; and providing encrypted communications between the agent and the service.

[0019] In some aspects, the techniques described herein relate to a method, wherein providing encrypted communications between the agent and the service includes: establishing an ephemeral key that is unique to the host between the agent and the service, and using the ephemeral key to encrypt information communicated between the agent and the service, wherein the ephemeral key is specific to the host.

[0020] In some aspects, the techniques described herein relate to a method, wherein the ephemeral key is established using one or more self-signed certificates generated by the agent.

[0021] In some aspects, the techniques described herein relate to a method, wherein: the certificate and the CA public key are generated in response to a request by the client device that includes a user public key, the request being sent to a validator associated with the CA, and responsive to receiving the certificate, the agent generates a self-signed certificate that is unique to the host and the agent.

[0022] In some aspects, the techniques described herein relate to a method, wherein: the agent is a bastion jump server, and providing encrypted communications between the bastion jump server and the service includes: minting, by the bastion jump server, a self-signed certificate that is associated with the secure access protocol, and using the self-signed certificate to establish an encrypted communication session with the service, the encrypted communication session including at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

[0023] In some aspects, the techniques described herein relate to a method, wherein the secure access protocol is secure shell (SSH), remote desktop protocol (RDP, Telnet, or virtual network computing (VNC).

[0024] In some aspects, the techniques described herein relate to a method, wherein the agent is an extended Berkley packet filter (eBPF) that uses eBPF hooks to perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.Docket No. 873003 (1065366 / WO / SEC / l)

[0025] In some aspects, the techniques described herein relate to a method, further including: using a process-level isolation mechanism to isolate the service such that only the agent can communicate with the service, wherein the process-level isolation mechanism includes at least one of Linux namespaces, IPTables mangling, eBPF hooks, tproxy, socket bind overrides, or configuration changes.

[0026] In some aspects, the techniques described herein relate to a method, wherein: the certificate includes time information representing a period to which a session of the secure access protocol is limited, establishing a secure access protocol between the agent and the client device is based on multifactor authentication, and the certificate communicates enforcement information to the agent and the enforcement information is specific to a user to whom the certificate is issued.

[0027] In some aspects, the techniques described herein relate to a computing apparatus including: one or more processors; and a memory storing instructions that, when executed by the one or more processors configure the computing apparatus to: perform any of the above methods.

[0028] In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to: perform any of the above methods.

[0029] In some aspects, the techniques described herein relate to a computing apparatus including: one or more processors; and a memory storing instructions that, when executed by the one or more processors configure the computing apparatus to: provide a service on a service endpoint running on a host; receive, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device; receive, at the host, a CA public key from the CA; interpose an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; and establish a secure access protocol between the agent and the client device.

[0030] In some aspects, the techniques described herein relate to a computing apparatus, wherein the instructions further configure the computing apparatus to: communicate between the agent and the client device using the secure access protocol: and provide encrypted communications between the agent and the service.

[0031] In some aspects, the techniques described herein relate to a computing apparatus, wherein the instructions cause the computing apparatus to provide encrypted communications between the agent and the service by configuring the computing apparatus to: establish anDocket No. 873003 (1065366 / WO / SEC / l)ephemeral key that is unique to the host between the agent and the service, and encrypt, using the ephemeral key, information communicated between the agent and the service, wherein the ephemeral key is specific to the host.

[0032] In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to: provide a service on a service endpoint running on a host; receive, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device; receive, at the host, a CA public key from the CA; interpose an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; and establish a secure access protocol between the agent and the client device.

[0033] In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein the instructions cause the computer to: communicate between the agent and the client device using the secure access protocol; and provide encrypted communications between the agent and the service.

[0034] In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein the instructions causing the computer to provide encrypted communications between the agent and the service further includes the instructions causing the computer to: establish an ephemeral key that is unique to the host between the agent and the service, and encrypt, using the ephemeral key, information communicated between the agent and the service, wherein the ephemeral key is specific to the host.EXAMPLE EMBODIMENTS

[0035] Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims or can be learned by the practice of the principles set forth herein.

[0036] The disclosed technology addresses the need in the art for the protection provided by a bastion jump server between a client and a server that can be implemented transparently, such that, from the perspectives of both the client and the server, the client and the server are directly interacting and neither the client nor the server is aware of an agent (e.g., the bastionDocket No. 873003 (1065366 / WO / SEC / l)jump server) being positioned between them. System and methods disclosed herein can be used as the agent providing the transparent bastion functionality a bastion jump server, an extended Berkley packet filter (eBPF), or a combination thereof.

[0037] According to certain non-limiting examples, the agent between the client device and the protected service provides various functionalities and benefits, including, for example, masquerading to the client device as the service endpoint, providing transparent interception, providing namespace isolation, and operating without a control plane.

[0038] According to certain non-limiting examples, the agent structure is a transparent proxy that masquerades as the service endpoint. For example, a bastion process operates co-resident with the protected service (e.g., SSH, RDP) on the same host system. By executing on the same system, the bastion process is granted access to the cryptographic materials of the protected service, including the server certificate and corresponding private key. This configuration enables the bastion to act as a transparent proxy, presenting itself to clients as the original protected service. In some implementations, any preexisting key material (e.g., authorized SSH public keys) may be removed or disabled, and replaced at runtime with an ephemeral cryptographic key that is generated locally and uniquely scoped to the host system. The ephemeral key may be used to generate a self-signed certificate, which is placed in the key store or certificate directory used by the protected service (e.g., the SSH key directory), thereby allowing the bastion to perform authenticated communication on behalf of the protected service.

[0039] According to certain non-limiting examples, the agent structure can perform transparent interception. For example, one or more techniques may be implemented on a host system to transparently intercept interactions with a protected service, including network traffic, filesystem access, and system call execution. For instance, extended Berkeley Packet Filter (eBPF) functionality may be utilized to implement interception across all three domains. In the networking domain, eBPF programs may be attached to relevant hooks to intercept incoming connection attempts directed to the protected service (e.g., TCP connections to port 22 for SSH) and redirect those connections to a bastion process rather than the originally targeted service daemon (e.g., SSHD). Similarly, eBPF may be employed to monitor or redirect filesystem operations associated with the protected service, enabling access control or contextual logging. In the context of active sessions (e.g., a shell session initiated via SSH), eBPF programs may be configured to observe and enforce policy on a pcr-scssion basis, such as by recording executed commands or restricting specific system calls, file operations, orDocket No. 873003 (1065366 / WO / SEC / l)command invocations. These techniques facilitate transparent policy enforcement and behavioral monitoring without requiring modifications to the protected service.

[0040] According to certain non-limiting examples, Linux namespaces or analogous isolation mechanisms may be employed to restrict communication with a protected service such that only a co-resident bastion process is capable of interacting with the service. This isolation may be achieved through various techniques, including but not limited to network namespaces, IPTables rules, eBPF-based packet filtering, transparent proxying (tproxy), socket binding overrides, and service-level configuration modifications. For example, the protected service (e.g., an SSH daemon) may be configured to listen within a dedicated network namespace that is only locally accessible on the host system. The bastion process, by contrast, may be configured to listen on public network interfaces formerly associated with the protected service, thereby presenting itself externally as the original service.

[0041] Upon receiving an incoming connection, the bastion process may accept a timelimited credential (e.g., a certificate with a defined validity window), evaluate policy constraints, and, if permitted, establish a proxied connection to the protected service using a standard man-in-the-middle (MITM) technique. Because the mutual TLS (mTLS) client key material is not available to the bastion, the bastion may generate a self-signed certificate that is injected into the certificate store of the protected service, thereby enabling the bastion to establish an authenticated session on behalf of the original client. This proxying process is transparent to the client and permits enforcement of additional controls such as session monitoring, command logging, and policy enforcement.

[0042] Further isolation may be implemented using filesystem namespaces. In this configuration, the file paths and configuration directories accessible to the protected service may be remapped to synthetic or minimal environments that differ from those exposed to the bastion process. This allows the bastion to access and manage the protected service’s original configurations and key material while exposing the protected service to only the minimal subset required for operation. As a result, the bastion can effectively masquerade as the protected service for purposes of external communication while maintaining a tightly scoped and isolated runtime environment for the protected service.

[0043] According to certain non-limiting examples, the agent structure can receive and enforce policies without a control plane. For example, by encoding policies in the certificate and enforcing them by the agent, the disclosed system eliminates the need for a control plane or direct communication between a centralized controller and individual agents (e.g., eBPG agents and / or bastion hosts). This decoupling is made possible through the use of a certificate-Docket No. 873003 (1065366 / WO / SEC / l)based trust model, wherein cross-signing techniques and metadata embedded in client certificates are leveraged to enforce session constraints and access policies, as described in greater detail elsewhere herein. The bastion process is configured to trust one or more certificate authorities (CAs) or subordinate certificate authorities (SubCAs) associated with the central ecosystem responsible for issuing client certificates, such as mutual TLS (mTLS) certificates. As a result, the bastion does not require runtime interaction with the central controller, but can instead validate incoming client certificates using pre-distributed CA public keys.

[0044] In addition, the protected service (e.g., an SSH daemon) is configured to trust a selfsigned certificate generated locally by the bastion system and is unique to the host. When a session is initiated and authenticated through the bastion, the bastion process generates a session-specific, self-signed certificate containing time-bound constraints that reflect those specified in the originating client certificate. This ephemeral certificate is placed into the certificate store of the protected service and used to establish the backend session between the bastion and the protected service.

[0045] Because the protected service is configured to trust only the locally generated certificate, rather than a broadly trusted global key, the system minimizes exposure and reduces the attack surface associated with unauthorized access. This localized trust boundary ensures that only the co-resident bastion process can establish authenticated sessions with the protected service, thereby enhancing isolation and control without requiring ongoing coordination with a centralized policy engine or management controller.

[0046] According to certain non-limiting examples, the certificate may carry policy directives in metadata fields such as principal name restrictions or URNs specifying allowed commands or session duration. The signed certificate is returned to the client, the client uses the certificate with its private key to initiate the SSH session securely. When establishing a secure access session (e.g., SSH or RDP), the client sends the signed certificate to the host running the protected service. For example, the client initiates the SSH handshake toward the service endpoint, presenting the signed certificate and proving possession of the matching private key via a certificate-verify step.

[0047] According to certain non-limiting examples, the host or a local enforcement agent parses embedded policy metadata (e.g., allowed host principals or command lists) and determines session-specific restrictions. Following authentication, a secure SSH channel is established via key exchange and session key derivation, ensuring confidentiality and integrity of communications. Commands issued over the secure channel are subject to policyDocket No. 873003 (1065366 / WO / SEC / l)enforcement based on metadata; for example, only a limited set of shell commands may be permitted.

[0048] According to certain non-limiting examples, the local enforcement agent is a bastion host interposed between the client and the protected service endpoint, enabling transparent mediation and policy enforcement.

[0049] For example, the bastion can use a kernel-level interception method (e.g., eBPF hook) to reroute incoming connections on service port 22 to the local bastion process without altering the client’s destination or configuration. Further, the bastion possesses the server's host certificate and presents it to the client during the handshake, making the client believe it is directly communicating with the protected service.

[0050] According to certain non-limiting examples, the bastion validates the client's signed certificate using the CA public key. It verifies signature, validity window, and policy metadata embedded in the certificate. Upon validation, the bastion generates or uses a short-lived host certificate trusted by the protected service, ensuring the service only accepts sessions proxied by the local bastion process.

[0051] According to certain non-limiting examples, the local enforcement agent uses eBPF agents to monitor system calls and user commands, enforcing policies like whitelisting allowed commands and blocking disallowed ones (e.g., sudo, rm -rf).

[0052] According to certain non-limiting examples, interactive session data — both user input and terminal output — can be recorded and forwarded to secure log storage for auditing and forensic investigation.

[0053] According to certain non-limiting examples, the bastion monitors certificate validity and terminates the session upon expiry, ensuring time-bounded access aligned with embedded certificate lease values. While depicted for SSH, the same architecture can enforce policies for other protocols that support mutual-TLS certificates, including RDP, HTTPS, and database access endpoints.

[0054] According to certain non-limiting examples, the bastion component can be deployed as a standalone host, a sidecar container, or an integrated kernel module, allowing adaptions to diverse infrastructure and tooling environments without modifying the protected service.

[0055] FIG. 1A illustrates a non-limiting example of system 100a for secure communications (e.g., secure-protocol communications 134) between client device 140 and host 148 using a certificate from certificate authority 114 that includes signed key 118. System 100a can include private key 104, user 106, public key 108, external IdP 110, validator / issuerDocket No. 873003 (1065366 / WO / SEC / l)112, certificate authority 114, service endpoint 116, signed key 118, secure shell endpoint 120, SSH CA public key 122, and protected service 146.

[0056] The secure communications are established using a series of preliminary communications among client device 140, host 148, and third parties (e.g., validator / issuer 112 and certificate authority 114). The preliminary communications include send public key for signing 126, authentication 128, return signed key 130, and establish secure-protocol session 132. In send public key for signing 126, client device 140 sends a request that includes public key 108 to validator / issuer 112 for signing a certificate. In authentication 128, identity information of user 106 is sent to an external identity provider (e.g., external IdP 110), which is a service that stores and manages digital identities, enabling users to access multiple applications or systems using a single set of credentials. Authentication 128 can also include identity information for Open authorization (OAuth), Security assertion markup language (SAML), or multifactor authentication (MFA).

[0057] After authenticating user 106, certificate authority 114 uses its private key to sign a certificate and validator / issuer 112 returns signed key 118 as part of the communications for return signed key 130. For example, signed key 118 is returned from validator / issuer 112 to user 106. In establish secure-protocol session 132, a handshake process is performed between client device 140 and host 148 using private key 104 and signed key 118 to initiate a secure access session (e.g., and SSH session) that is used for secure-protocol communications 134.

[0058] According to certain non-limiting examples, the certificate authority (CA) signs a public key certificate to verify the identity of the certificate holder and ensure its authenticity. The CA uses its private key to digitally sign the certificate, creating a digital signature that can be verified by anyone using the CA's public key. This process establishes a chain of trust, allowing relying parties to trust the certificate's validity and the identity it represents.

[0059] Digital certificates contain information about the certificate holder, the holder's public key, and other relevant details. The CA is a trusted third party that issues and manages digital certificates. Each CA has a private key that is kept secret and used for signing certificates. When a CA signs a certificate, it uses its private key to create a digital signature over the certificate's data. This signature acts like a fingerprint, uniquely identifying the CA as the issuer. When a user or application receives a certificate, they can verify the CA’s signature using the CA's public key. If the signature verifies correctly, it confirms that the certificate was issued by the trusted CA and has not been tampered with. Digital certificates can be part of a chain of trust, where one CA signs another CA's certificate, and so on, up toDocket No. 873003 (1065366 / WO / SEC / l)a root CA. This allows for a hierarchical system of trust, where the root CA is trusted by default by many systems.

[0060] According to certain non-limiting examples, the digital certificate is used to provides: authentication, encryption, and integrity. For example, the certificate can provide authentication by serving as a credential to validate the identity of the entity to which it is issued. Further, for example, the certificate can provide encryption for secure communication over insecure networks such as the Internet, and it can provide integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.

[0061] According to certain non-limiting examples, an applicant for a digital certificate will generate a key pair consisting of a private key and a public key, along with a certificate signing request (CSR). A CSR is an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.). Key pair and CSR generation are usually done on the server or workstation where the certificate will be installed, and the type of information included in the CSR varies depending on the validation level and intended use of the certificate. After generating the CSR, the applicant sends it to a CA, who independently verifies that the information it contains is correct and, if so, digitally signs the certificate with an issuing private key and sends it to the applicant.

[0062] When the signed certificate is presented to a recipient (e.g., host 148), the recipient can cryptographically confirm the CA’s digital signature via the CA’s public key. Additionally, the recipient can use the certificate to confirm that signed content was sent by someone in possession of the corresponding private key, and that the information has not been altered since it was signed. A key part of this aspect of the certificate is something called a chain of trust.

[0063] In SSL / TLS, S / MIME, code signing, and other applications of X.509 certificates, a hierarchy of certificates is used to verify the validity of a certificate’s issuer. This hierarchy is known as a chain of trust. In a chain of trust, certificates are issued and signed by certificates that live higher up in the hierarchy. A chain of trust can include: 1. A trust anchor, which is the originating certificate authority (CA). 2. At least one intermediate certificate, serving as “insulation” between the CA and the end-entity certificate. 3. The end-entity certificate, which is used to validate the identity of an entity such as a website, business, or person.Docket No. 873003 (1065366 / WO / SEC / l)

[0064] FIG. IB illustrates a non-limiting example of system 100b for secure communications between client device 140 and host 148 using a certificate from certificate authority 114 that includes signed key 118. In contrast to FIG. 1A, agent 144 is interposed between client device 140 and service endpoint 116 on which protected service 146 is running. Agent 144 can provide various functionalities including: (1) being transparent to client device 140 (and service endpoint 116), minimizing impact to the user experience (2) session recording monitoring, (3) enforcing policy controls and session timespan, and (4) command filtering.

[0065] Interposing agent 144 in the communication path can have many benefits. For example, agent 144 can be easily updated (e.g., more easily updated than patching an operating system or other software) such that when a vulnerability is detected, a compensating control can be quickly added to agent 144, until more permanent patches have been developed to remediate the vulnerability. Further, agent 144 is a transparent proxy that implements security policies and protection in a manner that is transparent, minimizing the impact on user experience.

[0066] According to certain non-limiting examples, agent 144 can leverage extended Berkley packet filters (eBPF) to provide visibility and enforcement. Additionally, agent 144 can provide communications that are cryptographically secure and time-bound. For example, encrypted communication 150 can use an ephemeral key that is unique to both host 148 and service endpoint 116. For example, host 148 can be running many virtual machines or containers that are operating as instances of service endpoint 116, and each of these can have a unique key to provide additional security.

[0067] According to certain non-limiting examples, agent 144 can use a multifactor authentication (MFA) workflow to lease a session for a specified timeframe. According to certain non-limiting examples, agent 144 can operate in a physical identity and access management (PIAM) ecosystem that enables policy controls around access and session leases. According to certain non-limiting examples, agent 144 can fully isolate secure shell (SSH) and remote desktop protocol (RDP) servers on the same host from external network access. According to certain non-limiting examples, agent 144 can use Mutual Transport Layer Security (mTLS) certificates for both the transparent bastion and the protected service (e.g., SSH or RDP).

[0068] According to certain non-limiting examples, agent 144 is a proxy that operates in a trust relationship with protected service (e.g., SSH or RDP) in which encrypted communications 150 use locally generated ephemeral keys having limited relevance to thatDocket No. 873003 (1065366 / WO / SEC / l)single host system. For example, agent 144 can generate a short-lived (ephemeral) key pair on host 148 in which the key pair is unique per session and not shared externally. Further, agent 144 can support session recording and monitoring, and agent 144 can support command controls based on a specific user, such as user #1 is limited to a subset of UNIX commands (e.g., only do 'Is' type shell commands).

[0069] The policy information that is enforced by agent 144 can be transmitted to agent 144 from client device 140 with the certificate during the process of establish secure-protocol session 132. For example, the policy information can be encoded in the metadata of the certificate, and the certificate can be transmitted to host 148 during an SSH handshake protocol.

[0070] According to certain non-limiting examples, the SSH handshake protocol can use certificate-based authentication in which client device 140 transmits the certificate metadata during the authentication phase, after the transport layer has been established. Initially, client device 140 and host 148 exchange version information and negotiate supported cryptographic algorithms. A key exchange (e.g. Diffie-Hellman or Curve25519) is then performed to derive a shared symmetric session key for encrypted communication. Once the secure channel is established, host 148 requests an authentication method. At this point, client device 140 sends the signed SSH certificate — issued by a trusted CA — alongside a proof of possession of the matching private key. The certificate contains identity information and validity metadata, and is presented as part of the public key authentication request. Host 148 validates the certificate using the CA’s trusted public key, checks time-bound fields like validity period, verifies allowed principals, and ensures the client’s private key corresponds to the public key in the certificate. After validation, the server issues a cryptographic challenge that the client signs with its private key. This signature, which the server verifies using the public key embedded in the certificate, proves the client possesses the private key without revealing it. If all checks pass, access is granted and an authenticated SSH session begins between agent 144 and client device 140.

[0071] As discussed below, agent 144 can be implemented using a bastion host (e.g., bastion jump server 102), an eBPF agent 142, or a combination thereof.

[0072] FIG. 1C illustrates a non-limiting example of system 100c in which an agent (e.g., bastion jump server 102, acts as a transparent proxy for service endpoint 116. According to certain non-limiting examples, bastion jump server 102 is an interposing agent that sits transparently between client and server, masquerading as the server, and inspects certificateDocket No. 873003 (1065366 / WO / SEC / l)metadata to determine session policy before proxying traffic. Here, bastion jump server 102 alone provides the functionality of agent 144.

[0073] System 100c can include bastion jump server 102, private key 104, user 106, public key 108, external IdP 110, validator / issuer 112, certificate authority 114, service endpoint 116, signed key 118, secure session endpoint 120, SSH CA public key 122, self-signed CA 138, and protected service 146.

[0074] As discussed above, system 100c includes various communication signals. The communication signal send public key for signing 126 includes sending public key 108 from user 106 to validator / issuer 112 for signing a certificate, and authentication 128 sends public key 108 to and external identity provider (e.g., external IdP 110), which is a service that stores and manages digital identities. For example, the combination of secure session endpoint 120, validator / issuer 112, and certificate authority 114 can enable users to access multiple applications or systems using a single set of credentials. Authentication 128 can also include identity information for Open authorization (OAuth), Security assertion markup language (SAML), or multifactor authentication (MFA).

[0075] In return signed key 130, signed key 118 is returned from validator / issuer 112 to user 106. Establish secure-protocol session 132 includes a handshake process being performed by client device 140 using private key 104 and signed key 118 to initiate an SSH communication protocol. An SSHD server certificate is presented to secure session endpoint 120. In generate and use ephemeral key 136, an ephemeral key is generated and used for encrypted communications between bastion jump server 102 and the SSH daemon (e.g., protected service 146) on the server (e.g., service endpoint 116).

[0076] Bastion jump server 102 provides transparent isolation 124 between the SSH daemon (e.g., protected service 146) on the server (e.g., service endpoint 116) and bastion jump server 102. Transparent isolation 124 can provide various functions, including session recording, policy controls, and session timespan enforcement.

[0077] According to certain non-limiting examples, system 100c is provided for establishing a secure, policy-controlled session between a client device and protected service 146, such as a remote access protocol endpoint (e.g., Secure Shell (SSH) or Remote Desktop Protocol (RDP)), through a transparent intermediary component (e.g., bastion jump server 102). The system includes client device 140 configured to generate a cryptographic key pair and to submit the public key to a validator / issuer service for certificate signing. The validator / issuer interacts with an external identity provider (IdP), which may support authentication mechanisms such as OAuth, Security Assertion Markup Language (SAML), or multi-factorDocket No. 873003 (1065366 / WO / SEC / l)authentication (MFA), to validate the client's identity and authorize session initiation. Upon successful validation, the validator / issuer transmits the public key to a certificate authority (CA), which issues a signed, time-bound certificate (i.e., an ephemeral certificate) binding the public key to the client identity and session constraints.

[0078] According to certain non-limiting examples, client device 140 uses the private key in combination with the signed certificate to initiate a connection with the bastion server using a secure communication protocol. The bastion server is configured to transparently interpose itself between the client and the protected service, masquerading as the destination endpoint. From the client’s perspective, the connection appears to terminate at the protected service. The bastion server uses its own server-side certificate (e.g., a certificate issued by a trusted CA or a self-signed certificate provisioned in accordance with the deployment environment) to present a valid server identity during the handshake phase of the secure communication protocol (e.g., the SSH handshake). The bastion validates the client’s certificate using a preprovisioned public key corresponding to the issuing CA.

[0079] Additionally or alternatively, bastion jump server 102 server can be configured with transparent enforcement capabilities implemented using kernel-level mechanisms such as extended Berkeley Packet Filter (eBPF) hooks. These mechanisms can enable enforcement of session policies, such as command-level restrictions, session time limits, and user-specific access rules, without modifying the protected service. For example, protected service 146, such as an SSH daemon (SSHD), is deployed within a constrained execution environment (e.g., using Linux namespaces) to ensure isolation from the external network and host file system. The SSHD instance may generate its own ephemeral keys and operate under local certificate authority constraints, while the bastion mediates all external communication.

[0080] Additionally or alternatively, the CA certificate used to validate signed client certificates is not obtained via a direct connection from the bastion to the certificate authority. Instead, the CA certificate is distributed to client device 140 server using an existing software or certificate management system, such as those employed in enterprise environments for configuration management or security updates, and client device 140 communicates the CA certificate to bastion jump server 102 via a handshake / authentication protocol to establish a secure access session. The system can avoid requiring a direct online trust path between the bastion and the CA, relying instead on standard certificate deployment practices. The clientspecific signed certificate thus serves as a cryptographically secure and time-bound session lease, enabling dynamic and auditable access control to the protected service via the intermediary bastion.Docket No. 873003 (1065366 / WO / SEC / l)

[0081] According to certain non-limiting examples, system 100c includes a bastion jump server deployed in front of protected services, such as SSH daemons, to serve as a transparent security layer. The objective is to mediate user access to these services without requiring changes to user clients or the protected service itself. To achieve this, the bastion runs on the same host as the protected service and shares access to its cryptographic credentials, including the private key and server certificate. This co-residency allows the bastion to masquerade as the protected service transparently, intercepting incoming connections without disrupting client-side configurations or workflows.

[0082] The bastion issues ephemeral SSH certificates that are time-bound, embedding session lifespan directly within the certificate using standard validity fields (e.g., “not before” and “not after”). This approach allows enforcement of session durations without requiring external coordination or control-plane signaling. When a user presents a client certificate signed by a central Certificate Authority (CA), the bastion validates it and, if approved, initiates a session with the protected service by issuing a locally scoped, self-signed certificate that is trusted only by the SSH daemon on that host. As a result, the SSH daemon accepts only those connections brokered by the co-located bastion.

[0083] This method enables control over session duration and access scope solely through certificate metadata, avoiding the complexity of maintaining a central control plane or distributed enforcement system. The bastion dynamically generates trusted certificates for each session, ensuring that the protected service cannot be accessed directly or by unauthorized entities. Since the SSH daemon trusts only the certificate issued by its local bastion, the trust boundary remains tightly confined to the host, reducing potential vectors for unauthorized access.

[0084] Additional capabilities such as session recording, command monitoring, and policy enforcement may be integrated within the bastion process. These functions can be enforced transparently, leveraging the bastion’s intermediary position and access to session metadata. Additionally or alternatively, extended features such as eBPF-based interception, namespace isolation, and syscall filtering can be introduced to provide more granular control over the interaction between the user and the protected service.

[0085] According to certain non-limiting examples, a system is configured to enable secure access to a protected computing resource using a certificate-based authentication mechanism associated with a secure communication protocol. A user device generates a cryptographic key pair comprising a private key and a corresponding public key. The public key is transmitted to a validation and issuance service, referred to herein as the validator / issuer. TheDocket No. 873003 (1065366 / WO / SEC / l)validator / issuer may enforce access control policies by interacting with an external identity provider that supports authentication protocols such as federated login, single sign-on, or multi-factor authentication.

[0086] Upon successful authentication of the user and validation of the access request, the validator / issuer transmits the public key to a certificate authority (CA). The CA generates a signed certificate that binds the public key to a set of usage constraints, validity parameters (e.g., start and expiration times), and identity metadata. The resulting signed certificate is returned to the user device and may be referred to as an ephemeral certificate due to its limited validity period.

[0087] To initiate a connection with the protected computing resource, the user device utilizes the secure communication protocol to present both the signed certificate and the corresponding private key to the server endpoint. The server is configured with a public verification key associated with the CA and verifies that the certificate has been signed by a trusted authority, is within its validity window, and satisfies any required access conditions (e.g., principal name, source address, or permitted actions).

[0088] In some implementations, the server may also present a server-side certificate signed by the same or a different CA, enabling mutual authentication between the client and the server. This enhances trust by allowing each party to verify the identity of the other.

[0089] The described system supports certificate-based access without requiring static public key distribution and enables time-bound, revocable session credentials. The authentication process may be augmented by session recording, command-level enforcement, or integration with policy-based access control mechanisms.

[0090] According to certain non-limiting examples, system 100c is provided for establishing a secure, policy-controlled session between a client device and a protected service, such as a remote access protocol endpoint (e.g., Secure Shell (SSH) or Remote Desktop Protocol (RDP)), through a transparent intermediary component referred to herein as a bastion server. The system includes a client device configured to generate a cryptographic key pair and to submit the public key to a validator / issuer service for certificate signing. The validator / issuer interacts with an external identity provider (IdP), which may support authentication mechanisms such as OAuth, Security Assertion Markup Language (SAML), or multi-factor authentication (MFA), to validate the client’s identity and authorize session initiation. Upon successful validation, the validator / issuer transmits the public key to a certificate authority (CA), which issues a signed, time-bound certificate (i.e., an ephemeral certificate) binding the public key to the client identity and session constraints.Docket No. 873003 (1065366 / WO / SEC / l)

[0091] According to certain non-limiting examples, the client device uses the private key in combination with the signed certificate to initiate a connection with the bastion server using a secure communication protocol. The bastion server is configured to transparently interpose itself between the client and the protected service, masquerading as the destination endpoint. From the client’s perspective, the connection appears to terminate at the protected service. The bastion server uses its own server-side certificate (e.g., a certificate issued by a trusted CA or a self-signed certificate provisioned in accordance with the deployment environment) to present a valid server identity during the handshake phase of the secure communication protocol (e.g., the SSH handshake). The bastion validates the client’s certificate using a preprovisioned public key corresponding to the issuing CA.

[0092] According to certain non-limiting examples, bastion jump server 102 can have transparent enforcement capabilities implemented using kernel-level mechanisms such as extended Berkeley Packet Filter (eBPF) hooks. These mechanisms enable enforcement of session policies, such as command-level restrictions, session time limits, and user-specific access rules, without modifying the protected service. In some non-limiting examples, the protected service, such as an SSH daemon (SSHD), is deployed within a constrained execution environment (e.g., using Linux namespaces) to ensure isolation from the external network and host file system. The SSHD instance may generate its own ephemeral keys and operate under local certificate authority constraints, while the bastion mediates all external communication.

[0093] In a further embodiment non-limiting example, the CA certificate used to validate signed client certificates is not obtained via a direct connection from the bastion to the certificate authority. Instead, the CA certificate is distributed to the bastion server using an existing software or certificate management system, such as those employed in enterprise environments for configuration management or security updates. System 100c does not require a direct online trust path between the bastion jump server 102 and certificate authority 114, relying instead on standard certificate deployment practices. The client-specific signed certificate can serve as a cryptographically secure and time-bound session lease, enabling dynamic and auditable access control to the protected service via the intermediary bastion.

[0094] FIG. ID illustrates a non-limiting example of system lOOd in which the agent providing the transparent bastion functionality is a combination of bastion jump server 102 and extended Berkley packet filter (eBPF) hooks 142a. System lOOd includes bastion jump server 102, private key 104, user 106, public key 108, external IdP 110, validator / issuer 112, certificate authority 114, service endpoint 116, signed key 118, secure session endpoint 120,Docket No. 873003 (1065366 / WO / SEC / l)SSH CA public key 122, self-signed CA 138, and eBPF hooks 142a. Here, a combination of eBPF agent 142 and bastion jump server 102 provide the functionality of agent 144.

[0095] Bastion jump server 102 provides encrypted communication between the SSH daemon (service endpoint 116) on the server and bastion jump server 102. eBPF hooks 142a can provide various functions, including session recording, policy controls, and session timespan enforcement.

[0096] According to certain non-limiting examples, In a non-limiting example that combines a bastion jump server with eBPF hooks, enforcement functions such as session recording, policy evaluation, and time-bound access control are delegated entirely to the eBPF layer. The bastion component remains present to facilitate network redirection, but all control logic is implemented via eBPF programs operating within the kernel. These programs can observe and act on user activity at the system call level, including process creation and termination, enabling precise monitoring and enforcement of user commands during SSH sessions.

[0097] Session metadata, such as permitted command sets or session duration, is embedded directly in the user’s client certificate as part of the authentication process. When a client initiates a connection and presents a certificate signed by a trusted certificate authority (CA), the eBPF subsystem inspects the certificate, extracts relevant metadata (e.g., not-before and not-after fields), and enforces session constraints accordingly. For instance, if the certificate indicates a one-hour validity window, the eBPF hook can monitor session start time and terminate the connection once the validity expires. Similarly, command-level restrictions can be enforced by inspecting process invocations during the session.

[0098] This approach operates without a central control plane, relying solely on the certificate metadata for enforcement logic. By pushing the policy information into the data plane and leveraging kernel-level visibility provided by eBPF, the system can scale without requiring communication with a centralized policy server. The SSH daemon continues to perform user authentication using the presented client certificate, while eBPF enforces constraints derived from the same certificate.

[0099] An alternative implementation omits the bastion host entirely, relying on eBPF hooks for both traffic redirection and enforcement. In such a configuration, eBPF intercepts incoming SSH traffic, validates client credentials, and applies access controls without introducing an intermediary process. This model assumes the underlying SSH daemon is patched or otherwise secured, as it does not offer the protocol-level isolation or compensating controls provided by the bastion.Docket No. 873003 (1065366 / WO / SEC / l)

[0100] Across both implementations, the combination of certificate-based signaling and kernel-level enforcement offers a flexible mechanism for securing access to protected services. Policies such as command filtering, session auditing, and session duration limits are specified declaratively within the certificate and executed at runtime without modifying the SSH daemon or requiring direct user involvement.

[0101] FIG. IE illustrates a non-limiting example of system lOOe in which the transparent bastion functionality is provided using eBPF hooks 142a. In system lOOe, there is no bastion jump server 102, and eBPF hooks 142a perform all SSH and policy enforcement functions. Here, eBPF agent 142 alone provides the functionality of agent 144.

[0102] In a non-limiting example that relies exclusively on eBPF hooks without the use of a bastion jump server, enforcement occurs entirely at the host level, outside the SSH protocol flow. In this approach, users connect directly to the protected service (e.g., SSHD), and the eBPF subsystem operates independently of the network or wire protocol. Once an SSH session is established, eBPF hooks monitor and control the commands executed within that session, such as those run through a bash shell. Policy enforcement — such as restricting specific commands, recording session activity, or applying time-based constraints — is performed locally at the kernel level, based on metadata embedded in the client certificate. This allows enforcement to occur transparently and post-authentication, without modifying the SSH protocol or requiring insertion into the connection handshake. The result is a method of controlling user behavior on the host without introducing additional network-layer components or interfering with protocol-level exchanges.

[0103] As discussed above, systems 100c, lOOd, and lOOe variously include an agent structure corresponding to agent 144 that enables the agent structure to masquerade as the service endpoint 116, provide transparent interception, provide namespace isolation, and operate without a control plane.

[0104] According to certain non-limiting examples, the agent structure is a transparent proxy that masquerade as the service endpoint. For example, a bastion process operates co-resident with the protected service (e.g., SSH, RDP) on the same host system. By executing on the same system, the bastion process is granted access to the cryptographic materials of the protected service, including the server certificate and corresponding private key. This configuration enables the bastion to act as a transparent proxy, presenting itself to clients as the original protected service. In some implementations, any preexisting key material (e.g., authorized SSH public keys) may be removed or disabled, and replaced at runtime with an ephemeral cryptographic key that is generated locally and uniquely scoped to the host system.Docket No. 873003 (1065366 / WO / SEC / l)The ephemeral key may be used to generate a self-signed certificate, which is placed in the key store or certificate directory used by the protected service (e.g., the SSH key directory), thereby allowing the bastion to perform authenticated communication on behalf of the protected service.

[0105] According to certain non-limiting examples, the agent structure can perform transparent interception. For example, one or more techniques may be implemented on a host system to transparently intercept interactions with a protected service, including network traffic, filesystem access, and system call execution. For instance, extended Berkeley Packet Filter (eBPF) functionality may be utilized to implement interception across all three domains. In the networking domain, eBPF programs may be attached to relevant hooks to intercept incoming connection attempts directed to the protected service (e.g., TCP connections to port 22 for SSH) and redirect those connections to a bastion process rather than the originally targeted service daemon (e.g., SSHD). Similarly, eBPF may be employed to monitor or redirect filesystem operations associated with the protected service, enabling access control or contextual logging. In the context of active sessions (e.g., a shell session initiated via SSH), eBPF programs may be configured to observe and enforce policy on a per-session basis, such as by recording executed commands or restricting specific system calls, file operations, or command invocations. These techniques facilitate transparent policy enforcement and behavioral monitoring without requiring modifications to the protected service.

[0106] According to certain non-limiting examples, Linux namespaces or analogous isolation mechanisms may be employed to restrict communication with a protected service such that only a co-resident bastion process is capable of interacting with the service. This isolation may be achieved through various techniques, including but not limited to network namespaces, IPTables rules, eBPF-based packet filtering, transparent proxying (tproxy), socket binding overrides, and service-level configuration modifications. For example, the protected service (e.g., an SSH daemon) may be configured to listen within a dedicated network namespace that is only locally accessible on the host system. The bastion process, by contrast, may be configured to listen on public network interfaces formerly associated with the protected service, thereby presenting itself externally as the original service.

[0107] Upon receiving an incoming connection, the bastion process may accept a timelimited credential (e.g., a certificate with a defined validity window), evaluate policy constraints, and, if permitted, establish a proxied connection to the protected service using a standard man-in-the-middle (MITM) technique. Because the mutual TLS (mTLS) client key material is not available to the bastion, the bastion may generate a self-signed certificate thatDocket No. 873003 (1065366 / WO / SEC / l)is injected into the certificate store of the protected service, thereby enabling the bastion to establish an authenticated session on behalf of the original client. This proxying process is transparent to the client and permits enforcement of additional controls such as session monitoring, command logging, and policy enforcement.

[0108] Further isolation may be implemented using filesystem namespaces. In this configuration, the file paths and configuration directories accessible to the protected service may be remapped to synthetic or minimal environments that differ from those exposed to the bastion process. This allows the bastion to access and manage the protected service’s original configurations and key material while exposing the protected service to only the minimal subset required for operation. As a result, the bastion can effectively masquerade as the protected service for purposes of external communication while maintaining a tightly scoped and isolated runtime environment for the protected service.

[0109] According to certain non-limiting examples, the agent structure can receive and enforce policies without a control plane. For example, by encoding policies in the certificate and enforcing them by the agent, the disclosed system eliminates the need for a control plane or direct communication between a centralized controller and individual agents (e.g., eBPG agents and / or bastion hosts). This decoupling is made possible through the use of a certificatebased trust model, wherein cross-signing techniques and metadata embedded in client certificates are leveraged to enforce session constraints and access policies, as described in greater detail elsewhere herein. The bastion process is configured to trust one or more certificate authorities (CAs) or subordinate certificate authorities (SubCAs) associated with the central ecosystem responsible for issuing client certificates, such as mutual TLS (mTLS) certificates. As a result, the bastion does not require runtime interaction with the central controller, but can instead validate incoming client certificates using pre-distributed CA public keys.

[0110] In addition, the protected service (e.g., an SSH daemon) is configured to trust a selfsigned certificate that is generated locally by the bastion system and is unique to the host. When a session is initiated and authenticated through the bastion, the bastion process generates a session-specific, self-signed certificate containing time-bound constraints that reflect those specified in the originating client certificate. This ephemeral certificate is placed into the certificate store of the protected service and used to establish the backend session between the bastion and the protected service.

[0111] Because the protected service is configured to trust only the locally generated certificate, rather than a broadly trusted global key, the system minimizes exposure andDocket No. 873003 (1065366 / WO / SEC / l)reduces the attack surface associated with unauthorized access. This localized trust boundary ensures that only the co-resident bastion process can establish authenticated sessions with the protected service, thereby enhancing isolation and control without requiring ongoing coordination with a centralized policy engine or management controller.

[0112] FIG. 2 illustrates an example flow diagram of method 200 for providing a protected service. Although the example flow diagram of method 200 depicts a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the function of method 200. In other examples, different components of an example device or system that implements method 200 may perform functions at substantially the same time or in a specific sequence.

[0113] According to some examples, the method includes providing a service on a service endpoint running on a host at block 202. For example, service endpoint 116 on host 148 illustrated in FIG. 1A may provide protected service 146. According to certain non-limiting examples, the protected service is an SSH daemon (SSHD).

[0114] According to some examples, the method includes receiving a client request for a certificate, validating the client, and generating the certificate at block 204. For example, validator / issuer 112 illustrated in FIG. 1A may receive a client request for a certificate, and a combination of external IdP 110, validator / issuer 112, and certificate authority 114 can validate the client, and generate the certificate. The request can be an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.).

[0115] According to some examples, the method includes receiving from the client device the certificate signed by a certificate authority (CA) and sent to the host from a client device at block 206. For example, host 148 illustrated in FIG. 1A may receive the certificate from client device 140. The certificate is signed by certificate authority 114 and sent to host 148 from client device 140.

[0116] According to certain non-limiting examples, the certificate includes time information representing a period to which a session of the secure access protocol is limited. The certificate communicates enforcement information to the agent, and the enforcement information is specific to a user to whom the certificate is issued.

[0117] According to some examples, the method includes receiving from the CA a CA public key at block 208. For example, host 148 illustrated in FIG. 1A may receive SSH CA public key 122 from certificate authority 114.Docket No. 873003 (1065366 / WO / SEC / l)

[0118] According to some examples, the method includes interposing an agent between the client device and the service on the service endpoint, and the agent operates as a transparent proxy by masquerading to the client device as the service endpoint at block 210. For example, the agent 144 illustrated in FIG. IB may be interposed between client device 140 and protected service 146 on service endpoint 116. Further, agent 144 can operate as a transparent proxy by masquerading to the client device as the service endpoint.

[0119] According to certain non-limiting examples, the agent is an extended Berkley packet filter (eBPF) that uses eBPF hooks to perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan. Alternatively, the agent can be a bastion jump server perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan. The agent can also be a combination of the bastion jump server and the eBPF agent, perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

[0120] According to some examples, the method includes establishing a secure access protocol between the agent and the client device at block 212. For example, agent 144 illustrated in FIG. IB may establish a secure access protocol with client device 140. According to certain non-limiting examples, the secure access protocol can be secure shell (SSH), remote desktop protocol (RDP), Telnet, or virtual network computing (VNC). Establishing the secure access protocol between the agent and the client device can be performed using multifactor authentication (MFA).

[0121] According to some examples, the method includes communicating between the agent and the client device using the secure access protocol at block 214. For example, agent 144 illustrated in FIG. IB may communicate with client device 140 using the secure access protocol.

[0122] According to some examples, the method includes providing encrypted communications between the agent and the service at block 216. For example, host 148 illustrated in FIG. 1A may provide encrypted communications between agent 144 and the protected service 146. The agent uses a process-level isolation mechanism to isolate the service such that only agent 144 can communicate with protected service 146. For example, the process-level isolation mechanism includes at least one of Linux namespaces, IPTables mangling, eBPF hooks, tproxy, socket bind overrides, or configuration changes.

[0123] According to some examples, the method includes establishing an ephemeral key that is unique to the host between the agent and the service at block 218. According to certainDocket No. 873003 (1065366 / WO / SEC / l)non-limiting examples, the ephemeral key is established using one or more self-signed certificates generated by the agent.

[0124] According to certain non-limiting examples, the agent is a bastion jump server, and the encrypted communications are provided between the bastion jump server and the protected service using the following steps. The bastion jump server mints a self-signed certificate that is associated with the secure access protocol. The self-signed certificate is used to establish an encrypted communication session with the service. The encrypted communication session includes the bastion jump server performing at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

[0125] According to some examples, the method includes using the ephemeral key to encrypt information communicated between the agent and the service at block 220. According to certain non-limiting examples, the ephemeral key is specific to the host.

[0126] FIG. 3A illustrates a non-limiting example of implementing extended Berkley pack filters (eBPF). The eBPF architecture 300 can be implemented on a central processing unit (CPU and includes a user space 302, kernel 304, and hardware 306. For example, the user space 302 can be a place where regular applications run, whereas the kernel 304 is where most operating system-related processes run. An eBPF in a processor at a node (e.g., a server or router) of the network can be used to perform the functions of agent 144, such as of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

[0127] The kernel 304 can have direct and full access to the hardware 306. When a given application in user space 302 connects to hardware 306, the application can do so via calling APIs in kernel 304. Separating the application and the hardware 306 can provide security benefits. An eBPF can allow user-space applications to package the logic to be executed in the kernel 304 without changing the kernel code or reloading.

[0128] Since eBPF programs run in the kernel 304, the eBPF programs can have visibility across all processes and applications, and, therefore, they can be used for many things: network performance, security, tracing, and firewalls.

[0129] The user space 302 can include a process 310, a user 308, and process 312. The kernel 304 can include a file descriptor 320, a virtual file system (e.g., VFS 322), a block device 324, sockets 326, a TCP / IP 328, and a network device 330. The hardware 306 can include storage 332 and network 334.

[0130] eBPF programs are event-driven and are run when the kernel or an application passes a certain hook point. Pre-defined hooks include system calls, function entry / exit, kernelDocket No. 873003 (1065366 / WO / SEC / l)tracepoints, network events, and several others. If a predefined hook does not exist for a particular need, it is possible to create a kernel probe (kprobe) or user probe (uprobe) to attach eBPF programs almost anywhere in kernel or user applications. When the desired hook has been identified, the eBPF program can be loaded into the kernel 304 using the bpf system call (e.g., syscall 316 or syscall 318). This is typically done using one of the available eBPF libraries. The next section provides an introduction into the available development toolchains. Verification of the eBPF program ensures that the eBPF program is safe to run. It validates that the program meets several conditions (e.g., the conditions can be that the process loading the eBPF program holds the required capabilities / privileges; the program does not crash or otherwise harm the system; and the program always runs to completion).

[0131] A benefit of the kernel 304 is abstracting the hardware (or virtual hardware) and providing a consistent API (system calls) allowing for applications to run and share the resources. To achieve this, a wide set of subsystems and layers are maintained to distribute these responsibilities. Each subsystem can allow for some level of configuration (e.g., configuration 314) to account for different needs of users. Each subsystem can allow for some level of configuration to account for the different needs of users. When a desired behavior cannot be configured, the kernel 304 can be modified to perform the desired behavior. This modification can be realized in three different ways: (1) by changing kernel source code, which may take a long time (e.g., several years) before a new kernel version becomes available with the desired functionality; (2) writing a kernel module, which may require regular editing (e.g., every kernel release) and incurs the added risk of corrupting the kernel 304 due to lack of security boundaries; or (3) writing an eBPF program that realizes the desired functionality. Beneficially, eBPF allows for reprogramming the behavior of the kernel 304 without requiring changes to kernel source code or loading a kernel module.

[0132] Many types of eBPF programs can be used, including socket filters and system call filters, networking, and tracing. Socket filter type eBPF programs can be used for network traffic filtering, and can be used for discarding or trimming of packets based on the return value. XDP type eBPF programs can be used to improve packet processing performance by providing a hook closer to the hardware (at the driver level), e.g., to access a packet before the operative system creates metadata. Tracepoint type eBPF programs can be used instrument kernel code, e.g., by attaching an eBPF program when a “perf” event is opened with a command “perf_event_open(2)”, then use the command “ioctl(2)” to return a file descriptor that can be used to enable the associated individual event or event group and to attach the eBPF program to the tracepoint event. Helper type eBPF programs can be used to determinesDocket No. 873003 (1065366 / WO / SEC / l)which subset of in kernel functions can be called. Helper functions are called from within eBPF programs to interact with the system, to operate on the data passed as context, or to interact with maps.

[0133] FIG. 3B illustrates just-in-time (JIT) compilation of eBPF programs. JIT compilation translates the generic bytecode of the program into the machine specific instruction set to optimize execution speed of the program. This makes eBPF programs run as efficiently as natively compiled kernel code or as code loaded as a kernel module.

[0134] An aspect of eBPF programs is the ability to share collected information and to store state information. For example, eBPF programs can leverage eBPF maps 336 to store and retrieve data in a wide set of data structures. The eBPF maps 336 can be accessed from eBPF program 338 and eBPF program 340 as well as from applications (e.g., process 310 and process 312) in user space 302 via a system call (e.g., syscall 316 and syscall 318). Nonlimiting examples of supported map types include, e.g., hash tables, arrays, least recently used (LRU), ring buffer, stack trace, and longest prefix match (LPM), which illustrates the diversity of data structures supported by eBPF programs.

[0135] FIG. 3C illustrates eBPF architecture 342 that uses eBPF hooks (e.g., LSM hook 348) to perform functions of agent 144. The eBPF architecture 342 illustrates the use of a Linux security module (LSM) to implement network / security functions at an endpoint in a network fabric (e.g., in the kernel spaces of a server or a client device. As discussed above, a process 310 in user space 302 results in a syscall 316 to kernel 304, and syscall 316 causes a dispatch syscall & look up entity 354, where the entity can be, e.g., a file, socket, or inode. After performing error checking (e.g., error checks 352), kernel 304 consults the discretionary access control (DAC) mechanism (e.g., DAC checks 350), and kernel 304 then calls the hooks (e.g., LSM hook 348), including hooks for the minor modules if any are present, followed by the hooks of the major security module in place at the time. To allow for module stacking, the security modules are separated into major modules and minor modules. There can only be one major security module running in a given system, while minor modules can be stacked to provide different security features. Historically, major modules had access to opaque security blobs provided by the LSM framework while minor modules did not, but this distinction is fading with more recent kernel releases.

[0136] LSM policy engine 358 can include eBPF program 344, eBPF program 346. and LSM policies 360. LSM policies 360 can include AppArmor and / or SELinux. When a hook in LSM hook 348 is triggered by syscall 316, LSM policy engine 358 determines one or more actions (e.g., security operation to be applied). Like the 5-tuple rules discussed with reference to FIG.Docket No. 873003 (1065366 / WO / SEC / l)2 can trigger respective actions (e.g., security operations), the hooks triggered at LSM hook 348 trigger respective actions, which are defined in LSM policy engine 358. These actions are defined in LSM policies 360, eBPF program 344, and / or eBPF program 346. There can be many different types of security hooks that trigger actions, including, e.g., security hooks for• file system operations;• opening, creating, moving, and deleting files;• mounting and unmounting file systems;• task / process operations;• allocating and freeing tasks, changing task user and group identities;• socket operations;• creating and binding sockets;• receiving and sending messages;• program execution operations;• mount using fs_context;• filesystem operations;• inode operations;• kernfs node operations;• file operations:• task operations;• Netlink messaging;• Unix domain networking;• socket operations;• SCTP;• Infiniband;• XFRM operations;• individual messages held in System V IPC message queues;• System V IPC Message Queues;• System V Shared Memory Segments;• System V Semaphores;• Audit;• the general notification queue;• using the eBPF maps and programs functionalities through;• perf events; andDocket No. 873003 (1065366 / WO / SEC / l)• io_uring.

[0137] According to certain non-limiting examples LSM policy engine 358 can be implemented using Kernel Runtime Security Instrumentation (KRSI), which can also be referred to as BPF-LSM. For example, a BPF-LSM program can be executed in the kernel with parsed information from the manager from the enforcement part. The BPF-LSM program can follow the LSM framework rule: checking the condition and returning the result. 0 means pass (Allow), or error code means not pass (Deny). For example, the BPF-LSM program can perform the steps of: (i) before the BPF-LSM program is attached to a particular LSM hook, the BPF-LSM program imports necessary libraries and creates data structures and events that will be collected from the kernel; (ii) once the BPF-LSM program is attached to the specific LSM hook, the BPF-LSM program performs:(l) filtering, (2) kernel context pre-processing, (3) a condition phase, and (4) a policy action. In the filtering, filters matched containers to control the behaviors. In the kernel context pre-processing: the program receives a kernel context observed only in the kernel. For example, the BPF-LSM program can pre-process the contexts for the corresponding LSM hook due to resource problems. In the condition phase, the BPF-LSM program can parse conditions that are used by a policy. For example, the conditions can decide whether the system call is safe to process. In the policy action, the BPF-LSM program can check security with an action. For example, the policy can give back the results of the LSM function to the program, such that if the action is “Allow”, the BPF-LSM program can return a value of “0,” otherwise the BPF-LSM program can return a value of “-1.” Policies in this system can be stackable to the old policies if the policy affects the same container.

[0138] According to certain non-limiting examples, when LSM policy engine 358 determines that accessing the entity (e.g., the entity can be a file, socket, or inode) is allowed, then the entity is accessed (e.g., access entity 356).

[0139] As discussed above, the LSM framework provides a modular architecture with built-in hooks in the kernel, allowing the installation of security modules to strengthen access control. The LSM framework can include at least four parts / components. First, the framework can include inserted calls to security hook functions at different key points in the kernel source code. Second, the framework can provide a generic security system call that allows security modules to write new system calls for security-related applications, styled similarly to the original Linux system call socketcall(), which is a multiplex system call. Third, the framework can implement registration and deregistration functions so that access control policies can be implemented as kernel modules (e.g., implemented through security_add_hooks andDocket No. 873003 (1065366 / WO / SEC / l)security_delete_hooks). Fourth, the framework can transform most of the capabilities logic into an optional security module.

[0140] According to certain non-limiting examples, the LSM framework controls operations on kernel objects by providing a series of hooks using the hook injection method. In the example of accessing the file open function process, the access diagram of hook functions can be implemented by: (1) after entering the kernel through a system call, the system performs an error check first; (2) once the error check passes, permission checks are performed (i.e., Discretionary Access Control (DAC) checks); and (3) after passing the permission checks, Mandatory Access Control (MAC) is enforced. For example, the permission checks can be based on user IDs by allowing resource access once the user ID is verified. Further, MAC can provide a type of access control that prohibits subjects from interfering, utilizing security labels, information classification, and sensitivity to control access, determining access based on comparing the subject's level and the sensitivity of the resource.

[0141] A non-limiting example of a data processing unit (DPU) is illustrated in FIG. 4. The DPU 402 can include two or more processing cores, for example. DPU 402 can be a hardware chip that is implemented in digital logic circuitry and can be used in any computing or network device. The DPU 402 can be used to perform the functions of agent 144, such as of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

[0142] DPU 402 can receive and transmit data packets via networking unit 404, which can be configured to function as an ingress port and egress port, enabling communications with one or more network devices, server devices (e.g., servers), random access memory, storage media (e.g., solid state drives (SSDs)), storage devices, or a data center fabric. The ports can include, e.g., a PCI-e port, Ethernet (wired or wireless) port, or other such communication media. Additionally or alternatively, DPU 402 can be implemented as an application-specific integrated circuit (ASIC), can be configurable to operate as a component of a network appliance or can be integrated with other DPUs within a device.

[0143] In FIG. 4, e.g., DPU 402 can include a plurality of programmable processing cores, including core 406a, core 406b, core 406c (which are collectively referred to as “cores 406”), and each of cores 406 can include an LI cache (e.g., LI cache 408a, LI cache 408b, ... , LI cache 408c). DPU 402 can include a memory unit 416. Memory unit 416 can include different types of memory or memory devices (e.g., coherent cache memory 420 and non-coherent buffer memory 418). In some examples, cores 406 can include at least two processing cores. DPU 402 also includes a networking unit 404, host units 410, a memory controller 414, andDocket No. 873003 (1065366 / WO / SEC / l)accelerators 412. Each of the cores 406, networking unit 404, memory controller 414, host units 410, accelerators 412, and memory unit 416, which includes coherent cache memory 420 and non-coherent buffer memory 418, can be connected to allow communication therebetween.

[0144] Cores 406 can comprise one or more of MIPS (microprocessor without interlocked pipeline stages) cores, ARM (advanced RISC (reduced instruction set computing) machine) cores, PowerPC (performance optimization with enhanced RISC-performance computing) cores, RISC-V (RISC five) cores, or CISC (complex instruction set computing or x86) cores. Each of cores 406 can be programmed to process one or more events or activities related to a given data packet such as, for example, a networking packet or a storage packet. Each of cores 406 can be programmable using a high-level programming language, e.g., C or C++.

[0145] The use of DPUs 402 can be beneficial for network processing of data flows. In some examples, cores 406 can be capable of processing data packets received by networking unit 404 and / or host units 410, in a sequential manner using one or more “work units.” In general, work units are sets of data exchanged between cores 406 and networking unit 404 and / or host units 410.

[0146] Memory controller 414 can control access to memory unit 416 by cores 406, networking unit 404, and any number of external devices, e.g., network devices, servers, or external storage devices. Memory controller 414 can be configured to perform a number of operations to perform memory management in accordance with the present disclosure. In some examples, memory controller 414 can be capable of mapping a virtual address to a physical address for non-coherent buffer memory 418 by performing a number of operations. In some examples, memory controller 414 can be capable of transferring ownership of a cache segment of the plurality of segments from core 406a to core 406b by performing a number of operations.

[0147] DPU 402 can act as a combination of a switch / router and a number of network interface cards. For example, networking unit 404 can be configured to receive one or more data packets from and transmit one or more data packets to one or more external devices, e.g., network devices. Networking unit 404 can perform network interface card functionality, and packet switching.

[0148] Additionally or alternatively, networking unit 404 can be configured to use large forwarding tables and offer programmability. Networking unit 404 can advertise Ethernet ports for connectivity to a network. In this way, DPU 402 supports one or more high-speed network interfaces, e.g., Ethernet ports, without the need for a separate network interface cardDocket No. 873003 (1065366 / WO / SEC / l)(NIC). Each of host units 410 can support one or more host interfaces, e.g., PCI-e ports, for connectivity to an application processor (e.g., an x86 processor of a server device or a local CPU or GPU of the device hosting DPU 402) or a storage device (e.g., an SSD). DPU 402 can also include one or more high bandwidth interfaces for connectivity to off-chip external memory (not illustrated in FIG. 4). Each of accelerators 412 can be configured to perform acceleration for various dala-processing functions, such as look-ups, matrix multiplication, cryptography, compression, or regular expressions. For example, accelerators 412 can comprise hardware implementations of look-up engines, matrix multipliers, cryptographic engines, compression engines, or regular expression interpreters.

[0149] DPU 402 can improve efficiency over x86 processors for targeted use cases, such as storage and networking input / output, security and network function virtualization (NFV), accelerated protocols, and as a software platform for certain applications (e.g., storage, security, and data ingestion). DPU 402 can provide storage aggregation (e.g., providing direct network access to flash memory, such as SSDs) and protocol acceleration. DPU 402 provides a programmable platform for storage virtualization and abstraction. DPU 402 can also perform firewall and address translation (NAT) processing, stateful deep packet inspection, and cryptography. The accelerated protocols can include TCP, UDP, TLS, IPSec (e.g., accelerates AES variants, SHA, and PKC), RDMA, and iSCSI. DPU 402 can also provide quality of service (QoS) and isolation containers for data, and provide LLVM binaries.

[0150] DPU 402 can support software including network protocol offload (TCP / IP acceleration, RDMA and RPC); initiator and target side storage (block and file protocols); high level (stream) application APIs (compute, network and storage (regions)); fine grain load balancing, traffic management, and QoS; network virtualization and network function virtualization (NFV); and firewall, security, deep packet inspection (DPI), and encryption (IPsec, SSL / TLS).

[0151] FIG. 5 illustrates a first non-limiting example of a multi-tier data center 500, which includes data center access 502, data center aggregation 504, and data center core 506. The data center 500 provides computational power, storage, and applications that can support an enterprise business, for example. The various processors, servers, routers, firewalls, and switches illustrated in the data center 500 can function as nodes in the network that apply security services to the data flow and generate the in-band and out-of-band information of the systems and methods disclosed herein.

[0152] The network design of the data center 500 can be based on a layered approach. The layered approach can provide improved scalability, performance, flexibility, resiliency, andDocket No. 873003 (1065366 / WO / SEC / l)maintenance. As shown in FIG. 5, the layers of the data center 500 can include the core, aggregation, and access layers (i.e., data center core 506, data center aggregation 504, and data center access 502).

[0153] The data center core 506 layer provides the high-speed packet switching backplane for all flows going in and out of the data center 500. The data center core 506 can provide connectivity to multiple aggregation modules and provides a resilient Layer 3 routed fabric with no single point of failure. The data center core 506 can run an interior routing protocol, such as Open Shortest Path First (OSPF) or Enhanced Interior Gateway Routing Protocol (EIGRP), and load balances traffic between the campus core and aggregation layers using forwarding-based hashing algorithms, for example.

[0154] The data center aggregation 504 layer can provide functions such as service module integration, Layer 2 domain definitions, spanning tree processing, and default gateway redundancy. Server- to- server multi-tier traffic can flow through the aggregation layer and can use services, such as firewalls and server load balancing, to optimize and secure applications. The smaller icons within the aggregation layer switch in FIG. 5 represents the integrated service modules. These modules provide services, such as content switching, firewall, SSL offload, intrusion detection, network analysis, and more.

[0155] The data center access 502 layer is where the servers physically attach to the network. The server components can be, e.g., 1RU servers, blade servers with integral switches, blade servers with pass-through cabling, clustered servers, and mainframes with OSA adapters. The access layer network infrastructure can include modular switches, fixed configuration 1 or 2RU switches, and integral blade server switches. Switches provide both Layer 2 and Layer 3 topologies, fulfilling the various server broadcast domain or administrative requirements.

[0156] The architecture in FIG. 5 is an example of a multi-tier data center, but server cluster data centers can also be used. The multi-tier approach can include web, application, and database tiers of servers. The multi-tier model can use software that runs as separate processes on the same machine using interprocess communication (IPG), or the multi-tier model can use software that runs on different machines with communications over the network. Typically, the following three tiers are used: (i) Web server; (ii) Application; and (iii) Database. Further, multi-tier server farms built with processes running on separate machines can provide improved resiliency and security. Resiliency is improved because a server can be taken out of service while the same function is still provided by another server belonging to the same application tier. Security is improved. For example, an attacker can compromise a web server without gaining access to the application or database servers. WebDocket No. 873003 (1065366 / WO / SEC / l)and application servers can coexist on a common physical server, but the database typically remains separate. Load balancing the network traffic among the tiers can provide resiliency, and security is achieved by placing firewalls between the tiers. Additionally, segregation between the tiers can be achieved by deploying a separate infrastructure composed of aggregation and access switches, or by using virtual local area networks (VLANs). Further, physical segregation can improve performance because each tier of servers is connected to dedicated hardware. The advantage of using logical segregation with VLANs is the reduced complexity of the server farm. The choice of physical segregation or logical segregation depends on your specific network performance requirements and traffic patterns.

[0157] The data center access 502 includes one or more access server clusters 508, which can include layer 2 access with clustering and NIC teaming. The access server clusters 508 can be connected via gigabit Ethernet (GigE) connections 510 to the workgroup switches 512. The access layer provides the physical level attachment to the server resources and operates in Layer 2 or Layer 3 modes for meeting particular server requirements such as NIC teaming, clustering, and broadcast containment.

[0158] The data center aggregation 504 can include aggregation processor 520, which is connected via 10 gigabit ethernet (10 GigE) connections 514 to the data center access 502 layer.

[0159] The aggregation layer can be responsible for aggregating the thousands of sessions leaving and entering the data center. The aggregation switches can support, e.g., many 10 GigE and GigE interconnects while providing a high-speed switching fabric with a high forwarding rate. The aggregation processor 520 can provide value-added services, such as server load balancing, firewalling, and SSL offloading to the servers across the access layer switches. The switches of the aggregation processor 520 can carry the workload of spanning tree processing and default gateway redundancy protocol processing.

[0160] For an enterprise data center, the data center aggregation 504 can contain at least one data center aggregation module that includes two switches (i.e., aggregation processors 520). The aggregation switch pairs work together to provide redundancy and to maintain the session state. The aggregation processors 520 can also support security and application devices and services.

[0161] Data center core 506 provides a fabric for high-speed packet switching between multiple aggregation modules. This layer serves as the gateway to the campus core 516 where other modules connect, including, for example, the extranet, wide area network (WAN), and internet edge. Links connecting the data center core 506 can be terminated at Layer 3 and useDocket No. 873003 (1065366 / WO / SEC / l)10 GigE interfaces to support a high level of throughput, performance, and to meet oversubscription levels. According to certain non-limiting examples, the data center core 506 is distinct from the campus core 516 layer, with different purposes and responsibilities. A data center core is not necessarily required, but is recommended when multiple aggregation modules are used for scalability. Even when a small number of aggregation modules are used, it might be appropriate to use the campus core for connecting the data center fabric.

[0162] Data center core 506 can connect, e.g., to the campus core 516 and data center aggregation 504 layers using Layer 3 -terminated 10 GigE links. Layer 3 links can be used to achieve bandwidth scalability, quick convergence, and to avoid path blocking or the risk of uncontrollable broadcast issues related to extending Layer 2 domains.

[0163] The traffic flow in the core can include sessions traveling between the campus core 516 and the aggregation processors 520. The data center core 506 aggregates the aggregation module traffic flows onto optimal paths to the campus core 516. Server-to-server traffic can remain within an aggregation processor 520, but backup and replication traffic can travel between aggregation processors 520 by way of the data center core 506.

[0164] The connections among the multilayer switches 518 enable traffic flow in the data center core to the clients in the campus core 516. The data center core 506 can connect to the campus core 516 and data center aggregation 504 layer using Layer 3-terminated 10 GigE links. Layer 3 links can be used to achieve bandwidth scalability, quick convergence, and to avoid path blocking or the risk of uncontrollable broadcast issues related to extending Layer 2 domains.

[0165] According to certain non-limiting examples, the traffic flow in the core consists primarily of sessions traveling between the campus core and the aggregation modules. The core aggregates the aggregation module traffic flows onto optimal paths to the campus core.

[0166] The traffic in the data center aggregation 504 layer primarily can include core layer to access layer flows. The core-to-access traffic flows can be associated with client HTTPbased requests to the web servers, the application servers, and the database servers. At least two equal cost routes exist to the web server subnets. The CISCO Express Forwarding (CEF)-based L3 plus L4 hashing algorithm determines how sessions balance across the equal cost paths. The web sessions might initially be directed to a VIP address that resides on a load balancer in the aggregation layer, or sent directly to the server farm. After the client request goes through the load balancer, it might then be directed to an SSL offload module or a transparent firewall before continuing to the actual server residing in the data center access 502.Docket No. 873003 (1065366 / WO / SEC / l)

[0167] FIG. 6 illustrates a subsystem 600, which is an example of a portion of a network system (e.g., a data center 500). Subsystem 600 provides an example of various components in which logical instructions can be implemented to configure the components as agent 144. For example, protected service 146 described above can be implemented in any of the servers (e.g., servers 612a, 612b, 612c, 614a, and 614b). The protected service can be executed on host (e.g., a CPU or virtual machine (VM) running on a CPU). Agent 144 can be implemented as a bastion jump server on one of the DPUs or implemented on one of the servers as a bastion jump server, as an eBPF agent, or a combination thereof.

[0168] The routers and switches can be implemented using a DPU. One or more parts of the deception (e.g., the lure part and / or the trap part) can be implemented in any of the DPUs (e.g., DPU 610a, DPU 610b, 610d, and DPU 610e) or in any of the eBPFs (e.g., eBPF 618 and eBPF 626)

[0169] Subsystem 600 includes ingress traffic 602 that flows into a router 604 that includes a firewall. A first part of the traffic is directed to switch 608a and passes through DPU 606a on the way to switch 608a. The first part of the traffic is then further subdivided into three streams that are relayed to server 612a, server 612b, and server 612c, and these three streams respectively pass through DPU 610a , DPU 610b , and CPU 610c on the way to server 612a, server 612b, and server 612c.

[0170] A second part of the traffic is directed to switch 608b and passes through DPU 606b on the way to switch 608b. The second part of the traffic is then further subdivided into two streams that are relayed to server 614a and server 614b by way of DPU 610d and DPU 610e, respectively.

[0171] Each of the workloads can be different (e.g., executing different applications with different susceptibilities to being exploited by cyber attacks) or can be the same. For example, if server 612a, server 612b, and server 612c are part of a cluster of workloads that are all executing the same applications, then the same types of deceptions might be applied to any one or more of these workloads.

[0172] Server 612b can include a CPU 622 on which a virtual machine (i.e. VM 624) is running, and VM 624 can include a kernel 628 that is accessed via eBPF 626. Server 612c can include a CPU 620 that has a kernel 616 and an eBPF 626. Any of the DPUs, switches, routers, and eBPFs can be network nodes that apply deceptions at their respective locations.

[0173] Further, deceptions can be applied to the data flow using the DPUs or eBPFs. The ME model to determine the optimal locations with the network for respective deceptions toDocket No. 873003 (1065366 / WO / SEC / l)provide a better solution with respect protecting against cyber attacks and efficiently allocating computational resources required.

[0174] As would be understood by a person of ordinary skill in the art, subsystem 600 provides a great deal of flexibility with respect to where agent 144 can be placed / configured to tailor the solution to a particular system architecture.

[0175] FIG. 7 shows an example of computing system 700, which can be for example any computing device making up system 100a, system 100b, system 100c, system lOOd, system lOOe, data center 500, subsystem 600, or any component thereof in which the components of the system are in communication with each other using connection 702. Connection 702 can be a physical connection via a bus, or a direct connection into processor 704, such as in a chipset architecture. Connection 702 can also be a virtual connection, networked connection, or logical connection.

[0176] In some embodiments, computing system 700 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some embodiments, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some embodiments, the components can be physical or virtual devices.

[0177] Example computing system 700 includes at least one processing unit (CPU or processor) processor 704 and connection 702 that couples various system components including system memory 708, such as read-only memory (e.g., ROM 710) and random access memory (e.g., RAM 712) to processor 704. Computing system 700 can include a cache of high-speed memory cache 706 connected directly with, in close proximity to, or integrated as part of processor 704.

[0178] Processor 704 can include any general-purpose processor and a hardware service or software service, such as service 716, service 718, and service 720 stored in storage device 714, configured to control processor 704 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 704 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0179] To enable user interaction, computing system 700 includes an input device 726, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech,Docket No. 873003 (1065366 / WO / SEC / l)etc. Computing system 700 can also include output device 722, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input / output to communicate with computing system 700. Computing system 700 can include communication interface 724, which can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0180] storage device 714 can be a non-volatile memory device and can be a hard disk or other types of computer-readable media that can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs), read-only memory (ROM), and / or some combination of these devices.

[0181] The storage device 714 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 704, it causes the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 704, connection 702, output device 722, etc., to carry out the function.

[0182] In summary, the present technology relates to providing secure access to a protected service through an intermediary agent that operates as a transparent proxy. The agent, which may be implemented using a bastion server, an extended Berkeley Packet Filter (eBPF) mechanism, or a combination of both, mediates communication between a client device and a service endpoint running on a host. The client presents a certificate signed by a certificate authority (CA), including user-specific metadata, policy directives, and session duration constraints. Upon receipt, the agent authenticates the certificate and establishes a secure session with the client using a secure access protocol such as SSH, RDP, or VNC. The agent enforces access policies, including session timespan, command restrictions, and user permissions. Communication between the agent and the protected service is encrypted using ephemeral keys generated by the agent, and isolation techniques ensure that only the agent can access the service endpoint.

[0183] For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices,Docket No. 873003 (1065366 / WO / SEC / l)device components, steps or routines in a method embodied in software, or combinations of hardware and software.

[0184] Any of the steps, operations, functions, or processes described herein may be performed or implemented by a combination of hardware and software services or services, alone or in combination with other devices. In some embodiments, a service can be software that resides in memory of a client device and / or one or more servers of a content management system and perform one or more functions when a processor executes the software associated with the service. In some embodiments, a service is a program, or a collection of programs that carry out a specific function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.

[0185] In some embodiments, the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0186] Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, For example, instructions and data which cause or otherwise configure a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, For example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, solid state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0187] Devices implementing methods according to these disclosures can comprise hardware, firmware and / or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.Docket No. 873003 (1065366 / WO / SEC / l)

[0188] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

[0189] Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and / or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims

Docket No. 873003 (1065366 / WO / SEC / l)CLAIMSWhat is claimed is:

1. A method for providing a protected service, the method comprising:providing a service on a service endpoint running on a host;receiving, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device;receiving, at the host, a CA public key from the CA;interposing an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; andestablishing a secure access protocol between the agent and the client device.

2. The method of claim 1, further comprising:communicating between the agent and the client device using the secure access protocol; andproviding encrypted communications between the agent and the service.

3. The method of claim 2, wherein providing encrypted communications between the agent and the service includes:establishing an ephemeral key that is unique to the host between the agent and the service, andusing the ephemeral key to encrypt information communicated between the agent and the service, whereinthe ephemeral key is specific to the host.

4. The method of claim 3. wherein the ephemeral key is established using one or more selfsigned certificates generated by the agent.

5. The method of any of claims 1 to 4, wherein:Docket No. 873003 (1065366 / WO / SEC / l)the certificate and the CA public key are generated in response to a request by the client device that includes a user public key, the request being sent to a validator associated with the CA, andresponsive to receiving the certificate, the agent generates a self-signed certificate that is unique to the host and the agent.

6. The method of any of claims 1 to 5, wherein:the agent is a bastion jump server, andproviding encrypted communications between the bastion jump server and the service includes:minting, by the bastion jump server, a self-signed certificate that is associated with the secure access protocol, andusing the self-signed certificate to establish an encrypted communication session with the service, the encrypted communication session including at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

7. The method of any of claims 1 to 6, wherein the agent is an extended Berkley packet filter (eBPF) that uses eBPF hooks to perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

8. The method of any of claims 1 to 7, further comprising:using a process-level isolation mechanism to isolate the service such that only the agent can communicate with the service, whereinthe process-level isolation mechanism includes at least one of Linux namespaces, IPTables mangling, eBPF hooks, tproxy, socket bind overrides, or configuration changes.

9. The method of any of claims 1 to 8, wherein:the certificate includes time information representing a period to which a session of the secure access protocol is limited,establishing a secure access protocol between the agent and the client device is based on multifactor authentication, andDocket No. 873003 (1065366 / WO / SEC / l)the certificate communicates enforcement information to the agent and the enforcement information is specific to a user to whom the certificate is issued.

10. A computing apparatus comprising:one or more processors; anda memory storing instructions that, when executed by the one or more processors configure the computing apparatus to:provide a service on a service endpoint running on a host;receive, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device;receive, at the host, a CA public key from the CA;interpose an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; andestablish a secure access protocol between the agent and the client device.

11. The computing apparatus of claim 10, wherein the instructions further configure the computing apparatus to:communicate between the agent and the client device using the secure access protocol; andprovide encrypted communications between the agent and the service.

12. The computing apparatus of claim 11, wherein the instructions cause the computing apparatus to provide encrypted communications between the agent and the service by configuring the computing apparatus to:establish an ephemeral key that is unique to the host between the agent and the service, andencrypt, using the ephemeral key, information communicated between the agent and the service, whereinthe ephemeral key is specific to the host.

13. The computing apparatus of any of claims 10 to 12, wherein:Docket No. 873003 (1065366 / WO / SEC / l)the certificate and the CA public key are generated in response to a request by the client device that includes a user public key, the request being sent to a validator associated with the CA, andresponsive to receiving the certificate, the agent generates a self-signed certificate that is unique to the host and the agent.

14. The computing apparatus of any of claims 10 to 13, wherein:the agent is a bastion jump server, andthe instructions cause the computing apparatus to provide encrypted communications between the agent and the service by configuring the computing apparatus to:mint, by the bastion jump server, a self-signed certificate that is associated with the secure access protocol, andestablish, using the self-signed certificate, an encrypted communication session with the service, the encrypted communication session including at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

15. The computing apparatus of any of claims 10 to 14, wherein the agent is an extended Berkley packet filter (eBPF) that uses eBPF hooks to perform at least one of session recording, enforcing policy controls, session monitoring, command filtering, or enforcing a session timespan.

16. The computing apparatus of any of claims 10 to 15, wherein the instructions further configure the computing apparatus to:use a process-level isolation mechanism to isolate the service such that only the agent can communicate with the service, whereinthe process-level isolation mechanism includes at least one of Linux namespaces, IPTables mangling, eBPF hooks, tproxy, socket bind overrides, or configuration changes.

17. The computing apparatus of any of claims 10 to 16, wherein:the certificate includes time information representing a period to which a session of the secure access protocol is limited,Docket No. 873003 (1065366 / WO / SEC / l)establishing a secure access protocol between the agent and the client device is based on multifactor authentication, andthe certificate communicates enforcement information to the agent and the enforcement information is specific to a user to whom the certificate is issued.

18. A non-transitory computer- readable storage medium, the computer-readable storage medium including instructions that when executed by a computer, cause the computer to:provide a service on a service endpoint running on a host;receive, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device;receive, at the host, a CA public key from the CA;interpose an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; andestablish a secure access protocol between the agent and the client device.

19. The non-transitory computer- readable storage medium of claim 18, wherein the instructions cause the computer to:communicate between the agent and the client device using the secure access protocol; andprovide encrypted communications between the agent and the service.

20. The non-transitory computer- readable storage medium of claim 19, wherein the instructions causing the computer to provide encrypted communications between the agent and the service further includes the instructions causing the computer to:establish an ephemeral key that is unique to the host between the agent and the service, andencrypt, using the ephemeral key, information communicated between the agent and the service, whereinthe ephemeral key is specific to the host.

21. A system for providing a protected service, the system comprising:Docket No. 873003 (1065366 / WO / SEC / l)means for providing a service on a service endpoint running on a host; means for receiving, at the host, a certificate signed by a certificate authority (CA) and sent to the host from a client device;means for receiving, at the host, a CA public key from the CA;means for interposing an agent between the client device and the service on the service endpoint, the agent operating as a transparent proxy by masquerading to the client device as the service endpoint; andmeans for establishing a secure access protocol between the agent and the client device.

22. The system according to claim 21 further comprising means for implementing the method according to any of claims 2 to 9.

23. A computer program, computer program product or computer readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method of any of claims 1 to 9.

Images