SECURING INTERNAL SERVICES IN A DISTRIBUTED ENVIRONMENT
Disclosed herein are methods, systems, and processes to secure internal services in a distributed computing environment. A service packet that includes a service call from a source appliance is intercepted at a server. A determination is made that the service call is for an internal service provided by the source appliance and includes client information with client process properties. The service packet is demultiplexed. A determination is made that rule attributes associated with the internal service match the client process properties. The client information is removed from the service packet and the service call is forwarded to the server.
The present patent application is a continuation of U.S. patent application Ser. No. 16/577,346, filed on Sep. 20, 2019, entitled “SECURING INTERNAL SERVICES IN A DISTRIBUTED ENVIRONMENT”, which is a continuation of U.S. patent application Ser. No. 15/911,519, filed on Mar. 5, 2018, entitled “SECURING INTERNAL SERVICES IN A DISTRIBUTED ENVIRONMENT”, which issued as U.S. Pat. No. 10,425,504 on Sep. 24, 2019, which is a continuation of U.S. patent application Ser. No. 15/010,487, filed on Jan. 29, 2016, entitled “SECURING INTERNAL SERVICES IN A DISTRIBUTED ENVIRONMENT”, issued as U.S. Pat. No. 9,912,783 on Mar. 6, 2018, all of which are incorporated by reference herein in their entirety and for all purposes.
FIELD OF THE DISCLOSUREThe present disclosure relates to data protection systems and, more particularly, to systems, methods, and processes to secure internal services in a distributed environment.
DESCRIPTION OF THE RELATED ARTBusinesses use appliances to provide business services to customers. Appliances can be hardware devices with integrated software (e.g., firmware), designed to provide one or more business services. Appliances can also be virtual appliances. Virtual appliances are preconfigured virtual machine images and can be created by installing software appliances on virtual machines. Unlike general purpose computers, appliances are not designed to allow users to change the software (including the underlying operating system).
Appliances can also be configured with hardware and/or software to enable them to function as clients and/or servers. An end user of these clients and/or servers need not understand the technical details of the underlying operating system running on the appliances because the hardware and/or software is preconfigured (e.g., by a manufacturer) and unmodifiable. In this manner, appliances are designed to be secure black boxes for the end user (e.g., a customer).
A cluster is a set of computing systems that are communicatively coupled to each other via a network (e.g., the Internet, and the like). Appliances can be deployed as discrete and separate computing systems in a cluster. For example, a first appliance hosting a client may request one or more internal services from a server hosted by a second appliance in the cluster.
The business service(s) provided by the first appliance often depend on these one or more internal services provided by the second appliance (e.g., a database server, and the like). These internal services are critical for the functioning of various appliances in the cluster and thus, must be protected from malicious attacks and/or security vulnerabilities.
SUMMARY OF THE DISCLOSUREDisclosed herein are methods, systems, and processes to secure internal services in a distributed environment. One such method involves intercepting a service call initiated by a client process of a client. In this example, the service call is a request for an internal service provided by a server. The client is deployed in a source appliance and the server is deployed in a target appliance. The service call includes an identifier and the identifier identifies the internal service. The method determines whether one or more rules of a plurality of rules are specified for the identifier. In response to the determination that one or more rules are specified, the method generates a service packet by multiplexing client information associated with the client process, and information in the service call, and forwards the service packet to the target appliance.
In one embodiment, the method accesses source kernel memory of the source appliance and retrieves the client information from source kernel memory. The client information includes one or more client process properties associated with the client process. In another embodiment, the method intercepts the forwarded service packet and demultiplexes the service packet to retrieve the client information. The method then processes one or more attributes of at least one rule using the client information and forwards the service call to the server, if the processing indicates that the forwarding the service call is allowable. The client process properties include but are not limited to a user context, a user group context, a client program name, a parent process name, and/or a terminal type.
In one embodiment, each rule of the one or more rules includes one or more (unique) attributes, and each attribute of one or more attributes corresponds to a client process property. In this example, the one or more rules are part of a rule set. The rule set is part of a source service call filter module as well as a target service call filter module. Source kernel includes a multiplexing module that performs the multiplexing, and target kernel includes a demultiplexing module that performs the demultiplexing.
In some embodiments, the method forwards the service call to the server if no rule is specified for the identifier. The processing includes determining whether each attribute of at least one rule matches a corresponding client process property.
In certain embodiments, the method accesses the rule set to determine whether the internal service identified by the identifier is unprotected or protected. In this example, the internal service is protected if the rule set includes at least one rule for the identifier specified in the service call, and the internal service is unprotected if the rule set includes no rules for the identifier specified in the service call.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations and omissions of detail; consequently those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any limiting. Other aspects, features, and advantages of the present disclosure, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
The present disclosure may be better understood, and its numerous objects and features made apparent to those skilled in the art, by referencing the accompanying drawings.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiments of the disclosure are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims.
DETAILED DESCRIPTION IntroductionAppliances are discrete hardware devices with integrated software (e.g., firmware), specifically designed to provide a specific computing resource (e.g., access to one or more business services). Appliances can also be virtual appliances. Virtual appliances are configured to provide similar functionality as dedicated hardware appliances, but virtual appliances are distributed (e.g., to customers), as software virtual machine images in a hypervisor, or for a hypervisor-enabled device. In addition, customers can deploy appliances by integrating the software (e.g., operating system (OS) software) and the hardware of a computing device.
Appliance have exactly one combination of hardware, operating system, and application software (e.g., application software that is required to provide business services). Therefore, appliances can be deployed and managed by customers without extensive Information Technology (IT) knowledge. Once deployed however, appliances do not permit (and are not designed to allow) customers to change (or modify) the software (e.g., OS software). Therefore, appliances are designed to be secure black boxes for customers.
Businesses use appliances to provide business services to customers. Software (e.g., application software and OS software in the appliance) that is configured provide these one or more business services (e.g., online banking, electronic commerce, and the like) requires one or more internal services for operation. For example, appliances can be configured to host a server that provides internal services such as database and/or web services required by the application software that provides online banking services.
Internal services are computing services (e.g., web services provided by a web server, database services provided by a database server, a message queue server, and the like) that are only provided to the software (e.g., application software and/or OS software) or the hardware of an appliance. Therefore, internal services provided by standalone appliances are not generally exposed to (and are not accessible by) users or other computing devices (e.g., external clients).
However, as previously noted, appliances can be deployed in a distributed computing environment (also called appliance ecosystem). For example, two or more appliances can be deployed in a cluster, a cloud, or in any multi-node computing environment to each perform different computing tasks and to provide various computing service(s). In such a distributed computing environment, appliances communicate with each other (e.g., via a network) to provide computing services to each other.
Deploying two or more appliances in such an appliance ecosystem exposes an appliance that provides internal services to other appliances in the appliance ecosystem (e.g., other appliances within same network, cloud, cluster, and the like). Therefore, unlike a standalone appliance, in a multi-node computing environment, an appliance that provides internal services is prone to security attacks from external clients too (e.g., from client programs that execute on a different appliance than the appliance that provides the internal services).
For example, a user with access to one appliance (any appliance/machine in the same network) can use a local client program (or even develop a custom client program) to initiate a connection request (or a service call) from that client program to another appliance that provides internal services to: (1) initiate a brute force attack (e.g., to gain sensitive information accessible to an internal service), (2) exploit security vulnerabilities of the internal service (e.g., by gaining root privilege using a reverse shell command), (3) initiate a Denial of Service (DoS) attack, and/or (4) initiate one or more of various other malicious attacks.
A firewall may be useful to secure appliances in a distributed computing environment (also called appliance ecosystem) from external threats and attacks (e.g., from computing systems and/or devices that operate outside the network, cloud, cluster, and the like). However, a firewall cannot prevent a first appliance (or any other system in the same network) from accessing and attacking internal services that are running on a second appliance, where both the first appliance and the second appliance are part of the same appliance ecosystem (e.g., part of the same network, cloud, cluster, and the like). In addition, because the software executing on an appliance cannot be modified by the customer and/or user, modifying the internal service to secure the internal service from external clients in the appliance ecosystem is not feasible.
Therefore, the above-mentioned security concerns are exacerbated if the client requesting an internal service and the server that provides the internal service are deployed on two separate appliances in a given appliance ecosystem. In this scenario, the internal service is exposed to external clients outside the appliance on which the internal service is executing (e.g., to other nodes, via the network). Although a firewall can define the boundary of the network (e.g., limit network communication between certain nodes in that network), the firewall cannot prevent one node that is part of the network from accessing and attacking (e.g., via a client program) internal services running on another node that is also part of the same network (or cloud, cluster, and the like).
Disclosed herein are methods, systems, and processes to secure internal services in a distributed environment and/or appliance ecosystem by only permitting connection/service requests (e.g, connect calls, service calls, and the like) for internal services from certain clients (e.g., client programs and/or client processes such as web services, internal scripts, maintenance and support users, and the like, that are required for the functioning of the appliance or appliance ecosystem) without modifying the internal services themselves.
It should be noted that the present application is related to the subject matter of application entitled “Securing Internal Services In An Appliance,” filed on the same day as the present application and having the same inventor and assignee, which is incorporated herein by reference, in its entirety and for all purposes.
Examples of an Appliance EcosystemSource appliance 105 and target appliance 150 can also execute or deploy any number of a variety of different software programs (e.g., a client program, a server program, and the like) on one or more virtual machines. Network 190 can be any type of network and/or interconnection (e.g., the Internet, a Wide Area Network (WAN), and the like).
Source appliance 105 includes a source processor 110 and a source memory 115. Source memory 115 implements a source operating system (OS) (not shown). Source OS executes a client 120 and includes a source kernel 135. Client 120 is a software program that is deployed on source appliance 105. Client 120 initiates a client process 125. Client process 125 requests access to an internal service using a service call 130. Source kernel 135 includes a source kernel memory 140 and a source service call filter module 145.
Target appliance 150 includes a target processor 155 and a target memory 160. Target memory 160 implements a target OS (not shown). Target OS executes a server 180 and includes a target kernel 165. Server 180 is a software program that is deployed on target appliance 150. Server 180 provides internal services 185(1)-(N) to one or more appliances (e.g., to source appliance 105 or another appliance on network 190). Target kernel 165 includes a client log 170 and a target service call filter module 175.
Client process properties 215(1)-(N) are properties (or details) associated with client process 125. In one embodiment, client process properties 215(1)-(N) include but are not limited to: (1) client program name (e.g., a client program name that executes client process 125), (2) parent process name (e.g., a parent process that executes client process 125), (3) user or user group context associated with client process 125, (4) terminal type of the client process (e.g., terminal type from where the client program is executed), and (5) one or more of various other client process properties.
Source service call filter module 145 is also part of source kernel 135 and is a kernel component. Source service call filter module 145 includes a rule set 225. Rule set 225 includes one or more rules (e.g., rule 230(1). Each internal service provided by one or more servers deployed on target appliance 150 corresponds to (and is identified by) a single (and unique) identifier (e.g., internal service 185(1) corresponds to identifier 220(1)). Each identifier also identifies one or more rules that must be fulfilled by a client process before client 120 is provided access to an internal service that corresponds to that identifier.
Identifier 220(1) corresponds to internal service 185(1). Therefore, access to internal service 185(1) requires a client process to meet or match all attributes specified in rule 230(1) or 230(2). In this example, identifier 220(1) is a port identifier and/or port number (e.g., each internal service has a unique port number). A port is an endpoint of communication in an OS.
In target appliance 150, a port identifier identifies a specific internal service. Once identified, a port identifier (e.g., an Internet socket port number) can be used to establish host-to-host connectivity (e.g., between client 120 and server 180). In other examples, identifier 220(1) can be any type of identifier (e.g., other than port numbers and/or port identifiers) that uniquely identifies an internal service.
Examples of Intercepting and Processing a Service Call in an Appliance EcosystemIn an appliance ecosystem, initiating service call 130 by client process 125 requires an Internet Protocol (IP) address and as well as a port number that the internal service binds to. For example, internal service 185(1) binds to identifier 220(1). The client process from client 120 to server 180 requires the creation of a socket call. Service call 130 can then be used to initiate the client process. In this example, service call 130 reaches internal services (or servers providing such internal services) executing on target appliance 150 via source kernel 135 and target kernel 165. The internal service accepts service call 130 and permits access to the resources provided by the internal service if certain conditions required by the internal service are met.
An internal service may not be able to verify client process properties associated with a client process (e.g., who initiated the service call, where the service call is coming from, and the like). Therefore, any client process in the appliance ecosystem can potentially initiate a service call. Consequently, in one embodiment, service call 130 specifies identifier 220(1) (e.g., a port number that corresponds to, identifies, and/or is related to a particular internal service provided by target appliance 150 as well as the IP address of the server that is providing the particular internal service).
In one embodiment, multiplexer module 240 intercepts service call 130 initiated by client process 125. In this example, service call 130 is a request for a particular internal service. The internal service is provided by server 180 implemented in target appliance 150. Multiplexer module 240 on source kernel 135 accesses rule 230(1) and determines whether the client process satisfies each (unique) attribute of at least one specified rule.
Demultiplexer module 250 then removes (extracts) the client information from the service packet, and forwards the service packet to the target appliance with only information specified in service call 130. Demultiplexer module 250 saves the client information on client log 170 (e.g., for auditing purposes). However, if service call 130 requests an internal service for which one or more rules are specified and/or defined in the rule set, and no client information (e.g., one or more client process properties that match each attribute of the one or more rules specified and/or defined for the internal service identified by the identifier in the service call) is part of the service packet (received from the multiplexer module), demultiplexer module 250 rejects service call 130 and transmits an error notification to client 120.
In some embodiments, the multiplexer module (or the source service call filter module) retrieves the port number (and the server/IP address) of the internal service from the identifier specified in the service call. Multiplexer module then accesses a rule set to determine whether the rule set specifies and/or defines one or more rules for the port number (e.g., indicating that the internal service that corresponds to the port number is a protected internal service). If no rule is specified and/or defined for the port number, the multiplexer module forwards the service call to the target appliance (e.g., as-is).
However, if the rule set does specify at least one rule for the port number identified in the identifier, the multiplexer module accesses source kernel memory (of the source appliance) and retrieves one or more client process properties (e.g., client (process) details/information) from source kernel memory (e.g., user context, client program name, parent process, and the like). Multiplexer module (or source service call filter module) multiplexes the one or more client process properties associated with the client process and retrieved from source kernel memory as well as the information specified in the service call (e.g., the identifier) and generates a service packet. Multiplexer module then forwards the multiplexed service packet to the target appliance over a network.
Once forwarded, demultiplexer module (or target service call filter module) receives the service packet before the service packet reaches the internal service (or server). Demultiplexer determines whether the service call is a request for an internal service for which at least one rule is specified and/or defined in the rule set. If no rule is specified for the internal service identified by the service call, demultiplexer module simply lets the service call continue to the internal service (or server) (e.g., because the internal service is an unprotected internal service).
However, if at least one rule is specified in the rule set for the internal service identified in the service call, demultiplexer module determines whether the service packet includes client information (e.g., one or more client process properties applicable to the client process that initiates the service call). If no client information is available in the service packet, demultiplexer module rejects the service call and sends a reject notification to the client.
However, if the service packet includes client information (e.g., one or more client process properties), demultiplexer module demultiplexes the service packet to obtain the client process properties. Demultiplexer module then compares the each attribute of at least one rule to corresponding client process properties.
If each attribute of at least one rule that is specified and/or defined for the internal service matches a corresponding client process property, demultiplexer module removes the client information (e.g., client process details and/or client process properties) from the service packet, and forwards the service call (as part of the service packet) to the server. If no match is found, demultiplexer module rejects the service call.
Example Processes to Secure Internal Services in a Distributed EnvironmentAt 460, the process multiplexes the client process properties (e.g., client information) and the information in the service call (e.g., a port identifier, and a system address and/or IP address), and at 470 generates a service packet. In this example, the service packet is an update to a network packet that is sent by the service call and includes the identifier (e.g., service call information). The network packet is updated to generate the service packet by including the client information associated with the client process (e.g., user context, client program name, parent process name, terminal type, and the like). The process ends at 480 by forwarding the service packet to the target appliance.
However, if at least one rule is specified for the internal service, the process, at 530, determines whether the service packet includes client information (e.g., one or more client process properties). If the service packet does not include client process properties, the process ends at 540 by rejecting the service call. However, if the service packet does include client process properties, the process, at 550, demultiplexes the service packet.
At 560, the process determines whether each attribute of at least one rule specified and/or defined for the internal service matches a corresponding client process property (of the client process properties included in and part of the service packet). If each attribute of none of the rule(s) match the corresponding client process property, the process ends at 540 by rejecting the service call. However, if each attribute of at least one rule matches the corresponding client process property, the process, at 570, removes the client information (e.g., the client process properties) from the (received) service packet, and ends at 580 by forwarding the service call to the server.
Other EmbodimentsIt should be noted that the client information (e.g., client information 235) is received by the target service call filter module (or demultiplexer module) by intercepting the multiplexed packet (e.g., the service packet) forwarded by the source service call filter module (or multiplexer module). The multiplexed packet (e.g., the service packet) contains the client information. The client information does not exist in the target kernel. The multiplexer module intercepts the connect( ) system call (e.g., connect call 315), and the demultiplexer module intercepts the accept( ) system call (e.g., accept call 350).
A client on another (non-appliance) system in the same network can also try to initiate a service call to an internal service on an appliance. In this case, the demultiplexer module will not receive the client properties as there is no multiplexer on the source system. Therefore, the demultiplexer module will reject the service call for the protected internal service.
An Example Computing EnvironmentProcessor 110/155 generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. Processor 110/155 may receive instructions from a software application or module. These instructions may cause processor 110/155 to perform the functions of one or more of the embodiments described and/or illustrated herein. For example, processor 110/155 may perform and/or be a means for performing all or some of the operations, methods, or processes described and/or illustrated herein.
Memory 115/160 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or other computer-readable instructions. Examples include, without limitation, random access memory (RAM), read only memory (ROM), flash memory, and the like. Computing system 600 may include both a volatile memory unit and a non-volatile storage device. Program instructions implementing a multiplexer module and/or a demultiplexer module may be loaded into memory 115/160 respectively.
In certain embodiments, computing system 600 may also include one or more components or elements in addition to processors 110/155 and memory 115/160. For example, as illustrated in
Memory controller 620 generally represents any type or form of device capable of handling memory or data or controlling communication between one or more components of computing system 600. For example, in certain embodiments memory controller 620 may control communication between processors 110/155, memory 115/160, and I/O controller 635 via communication infrastructure 605. In certain embodiments, memory controller 620 may perform and/or be a means for performing, either alone or in combination with other elements, one or more of the operations or features described and/or illustrated herein.
I/O controller 635 generally represents any type or form of module capable of coordinating and/or controlling the input and output functions of a computing device. For example, I/O controller 635 may control or facilitate transfer of data between one or more elements of computing system 600, such as processors 110/155, memory 115/160, communication interface 650, display adapter 615, input interface 625, and storage interface 640.
Communication interface 650 broadly represents any type or form of communication device or adapter capable of facilitating communication between computing system 600 and one or more additional devices. For example, in certain embodiments communication interface 650 may facilitate communication between the primary and secondary appliances and a private or public network including additional computing systems. Examples of communication interface 650 include, without limitation, a wired network interface (such as a network interface card), a wireless network interface (such as a wireless network interface card), a modem, and any other suitable interface. In at least one embodiment, communication interface 650 may provide a direct connection to a remote server via a direct link to a network, such as the Internet. Communication interface 650 may also indirectly provide such a connection through, for example, a local area network (such as an Ethernet network), a personal area network, a telephone or cable network, a cellular telephone connection, a satellite data connection, or any other suitable connection.
In some embodiments, communication interface 650 may also represent a host adapter configured to facilitate communication between computing system 600 and one or more additional network or storage devices via an external bus or communications channel. Examples of host adapters include, without limitation, Small Computer System Interface (SCSI) host adapters, Universal Serial Bus (USB) host adapters, Institute of Electrical and Electronics Engineers (IEEE) 1394 host adapters, Serial Advanced Technology Attachment (SATA), Serial Attached SCSI (SAS), and external SATA (eSATA) host adapters, Advanced Technology Attachment (ATA) and Parallel ATA (PATA) host adapters, Fibre Channel interface adapters, Ethernet adapters, or the like. Communication interface 650 may also allow computing system 600 to engage in distributed or remote computing. Communication interface 650 may receive instructions from a remote device or send instructions to a remote device for execution.
Computing system 600 may also include at least one display device 610 coupled to communication infrastructure 605 via a display adapter 615. Display device 610 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 615. Similarly, display adapter 615 generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure 605 (or from a frame buffer, as known in the art) for display on display device 610.
Computing system 600 may also include at least one input device 630 coupled to communication infrastructure 605 via an input interface 625. Input device 630 generally represents any type or form of input device capable of providing input, either computer or human generated, to computing system 600. Examples of input device 630 include, without limitation, a keyboard, a pointing device, a speech recognition device, or any other input device.
Computing system 600 may also include storage device 645 coupled to communication infrastructure 605 via a storage interface 640. Storage device 645 generally represents any type or form of storage devices or mediums capable of storing data and/or other computer-readable instructions. For example, storage device 645 may include a magnetic disk drive (e.g., a so-called hard drive), a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash drive, or the like. Storage interface 640 generally represents any type or form of interface or device for transferring and/or transmitting data between storage device 645, and other components of computing system 600. In certain embodiments, storage device 645 may be configured to read from and/or write to a removable storage unit configured to store computer software, data, or other computer-readable information. Examples of removable storage units include, without limitation, a floppy disk, a magnetic tape, an optical disk, a flash memory device, or the like. Storage device 645 may also include other similar structures or devices for allowing computer software, data, or other computer-readable instructions to be loaded into computing system 600 (e.g., to read and write software, data, or other computer-readable information). Storage device 645 may also be a part of computing system 600 or may be separate devices accessed through other interface systems.
Many other devices or subsystems may be connected to computing system 600. Conversely, all of the components and devices illustrated in
The computer-readable medium containing the computer program may be loaded into computing system 600. All or a portion of the computer program stored on the computer-readable medium may then be stored in memory 115/160 and/or storage device 645. When executed by processor 110/155, a computer program loaded into computing system 600 may cause processor 110/155 to perform and/or be a means for performing the functions of one or more of the embodiments described and/or illustrated herein. One or more of the embodiments described and/or illustrated herein may be implemented in firmware and/or hardware. For example, computing system 600 may be configured as an application specific integrated circuit (ASIC) adapted to implement one or more of the embodiments disclosed herein.
An Example Networking EnvironmentNetwork 190 generally represents any type or form of computer network or architecture capable of facilitating communication between multiple computing devices. Network 190 may facilitate communication between source appliance 105 and target appliance 150. In certain embodiments, a communication interface, such as communication interface 650 in
In some examples, all or a portion of the computing devices in
In addition, one or more of the components described herein may transform data, physical devices, and/or representations of physical devices from one form to another. For example, source appliance 105 and/or target appliance 150 may transform behavior of a computing device, cluster, and/or server in order to cause the computing device, cluster, and/or server to secure internal services in a distributed (e.g., multi-appliance) environment.
Although the present disclosure has been described in connection with several embodiments, the disclosure is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the disclosure as defined by the appended claims.
Claims
1.-20. (canceled)
21. A computer-implemented method comprising:
- intercepting a service call initiated by a client process of a client, wherein the service call is a request for an internal service, the internal service is provided by a server, the service call comprises an identifier, and the identifier identifies the internal service;
- determining whether one or more rules of a plurality of rules are specified for the identifier;
- in response to a determination that the one or more rules are specified for the identifier, processing one or more attributes of the one or more rules, and forwarding the service call to the server, if the processing indicates that the forwarding the service call is allowable; and
- in response to a determination that none of the plurality of rules are specified for the identifier, forwarding the service call to the server.
22. The computer-implemented method of claim 21, further comprising:
- retrieving one or more client process properties of a plurality of client process properties associated with the client process from kernel memory.
23. The computer-implemented method of claim 21, wherein
- the identifier is a port identifier or a port number.
24. The method of claim 22, wherein
- the plurality of client process properties comprise a user context, a user group context, a client program name, a parent process name, or a terminal type.
25. The computer-implemented method of claim 22, further comprising:
- forwarding the service call to the server if each attribute of the one or more attributes of at least one rule matches a corresponding client process property of the one or more client process properties.
26. The computer-implemented method of claim 25, further comprising:
- generating a reject notification if at least one client process property of the one or more client process properties does not match each attribute; and
- sending the reject notification to the client.
27. The computer-implemented method of claim 26, wherein
- a first attribute of the one or more attributes of a first rule of the one or more rules corresponds to a first client process property of the one or more client process properties, and
- a second attribute of the one or more attributes of a second rule of the one or more rules corresponds to a second client process property of the one or more client process properties.
28. The computer-implemented method of claim 22, wherein
- the plurality of rules are part of a rule set,
- the rule set is part of a service call filter module, and
- the service call filter module is part of a kernel.
29. The computer-implemented method of claim 28, further comprising:
- accessing the rule set to determine whether the internal service identified by the identifier is unprotected or protected.
30. The computer-implemented method of claim 29, wherein
- the internal service is protected if the rule set comprises at least one rule of the plurality of rules for the identifier specified in the service call, and
- the internal service is unprotected if the rule set does not comprise at least one rule of the plurality of rules for the internal service specified in the service call.
31. The method of claim 30, further comprising:
- forwarding the service call to the server if the internal service is unprotected, or each attribute of the at least one rule matches the corresponding client process property of the one or more client process properties.
32. The computer-implemented method of claim 21, wherein
- the client and the server are deployed in an appliance.
33. The computer-implemented method of claim 21, further comprising:
- in response to the determination that the one or more rules are specified for the identifier, rejecting the service call, if the one or more rules indicate that the service call should not be forwarded to the first server.
34. The computer-implemented method of claim 21, further comprising:
- the service call is intercepted by a service call filter module executing in a kernel,
- the service call filter module comprises a rule set that is stored in the kernel memory, and
- the forwarding the service call to the server is performed without accessing kernel memory.
35. A non-transitory computer readable storage medium storing program instructions executable to perform a method comprising:
- intercepting a service call initiated by a client process of a client, wherein the service call is a request for an internal service, the internal service is provided by a server, the service call comprises an identifier, and the identifier identifies the internal service;
- determining whether one or more rules of a plurality of rules are specified for the identifier;
- in response to a determination that the one or more rules are specified for the identifier, processing one or more attributes of the one or more rules, and forwarding the service call to the server, if the processing indicates that the forwarding the service call is allowable; and
- in response to a determination that none of the plurality of rules are specified for the identifier, forwarding the service call to the server.
36. The non-transitory computer readable storage medium of claim 35, wherein the method further comprises:
- retrieving one or more client process properties of a plurality of client process properties associated with the client process from kernel memory, wherein the plurality of client process properties comprise a user context, a user group context, a client program name, a parent process name, or a terminal type;
- forwarding the service call to the server if each attribute of the one or more attributes of at least one rule matches a corresponding client process property of the one or more client process properties;
- generating a reject notification if at least one client process property of the one or more client process properties does not match each attribute; and
- sending the reject notification to the client.
37. The non-transitory computer readable storage medium of claim 35, wherein the method further comprises:
- accessing the rule set to determine whether the internal service identified by the identifier is unprotected or protected, wherein the plurality of rules are part of a rule set, the rule set is part of a service call filter module, the service call filter module is part of a kernel, the internal service is protected if the rule set comprises at least one rule of the plurality of rules for the identifier specified in the service call, and the internal service is unprotected if the rule set does not comprise at least one rule of the plurality of rules for the internal service specified in the service call; and
- forwarding the service call to the server if the internal service is unprotected, or each attribute of the at least one rule matches the corresponding client process property of the one or more client process properties.
38. The non-transitory computer readable storage medium of claim 35, wherein the method further comprises:
- in response to the determination that the one or more rules are specified for the identifier, rejecting the service call, if the one or more rules indicate that the service call should not be forwarded to the first server.
39. The non-transitory computer readable storage medium of claim 35, wherein the method further comprises:
- the service call is intercepted by a service call filter module executing in a kernel,
- the service call filter module comprises a rule set that is stored in the kernel memory, and
- the forwarding the service call to the server is performed without accessing kernel memory.
40. A computer-implemented method comprising:
- intercepting, by a service call filter module executing in a kernel, a service call initiated by a client process of a client executing in a first portion of a first user space of a first appliance, wherein the service call is a request for a service comprising an identifier that identifies the service, and the service call filter module comprises a rule set;
- determining whether the service is an internal service, wherein the internal service is provided by a first server executing in a second portion of the first user space of the first appliance;
- in response to a determination that the service is the internal service, determining whether one or more rules of a plurality of rules are specified for the internal service identified by the identifier, wherein the determining is performed by the service call filter module accessing the rule set, and in response to a determination that the one or more rules are specified for the internal service identified by the identifier, determining whether to forward the service call to the first server by applying the one or more rules to the service call, and forwarding the service call to the first server, if the one or more rules indicate that the service call should be forwarded to the first server; and
- in response to a determination that the service is not the internal service, forwarding the service call to a second appliance, wherein the service is another service that is provided by a second server executing in a portion of a second user space of the second appliance, and the service call is forwarded to the second appliance without applying any of the plurality of rules to the service call.
Type: Application
Filed: Mar 22, 2021
Publication Date: Sep 2, 2021
Inventor: Vikas Goel (Sunnyvale, CA)
Application Number: 17/208,254