Patent Description:
Businesses use appliances to provide business services to customers. An appliance can be a hardware device with integrated software (e.g., firmware), designed to provide one or more business services. An appliance can also be a virtual appliance. A virtual appliance is a pre-configured virtual machine image and can be created by installing a software appliance on a virtual machine. Unlike general purpose computers, an appliance is 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 appliance 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).

The business service(s) provided by an appliance often depend on one or more internal services provided by the appliance (e.g., a database server, and the like). These internal services are critical for the functioning of the appliance and thus, must be protected from malicious attacks and/or security vulnerabilities. <CIT> discloses methods, systems, and apparatus for object invocation across protection domain boundaries.

Disclosed herein are methods, systems, and processes to secure internal services in an appliance. One such method involves intercepting a service call initiated by a client process of a client. The service call is a request for an internal service provided by a server. The client and the server are deployed in an appliance. The service call comprises an identifier and the identifier identifies the internal service. The method determines whether one or more rules are specified for the identifier. In response to the determination that one or more rules are specified, the method processes one or more attributes of the one or more rules specified. The method then forwards the service call to the server, if the processing indicates that the forwarding the service call is allowable.

In one embodiment, the method retrieves one or more client process properties from kernel memory. The kernel memory stores client process properties associated with a client process. In this example, the identifier is a port identifier or a port number. 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, or a terminal type.

In some embodiments, the method forwards the service call to the server if each attribute one or more rules specified for the internal service matches a corresponding client process property retrieved from kernel memory. In other embodiments, the method forwards the service call to the server without accessing kernel memory, if at least one rule of the one or more rules is not specified (e.g., no rule is defined) for the internal service identified by the identifier.

In certain embodiments, the method generates a reject notification (e.g., with an error operation) if each attribute of the one or more rules specified does not match at least one client process property of the one or more client process properties retrieved from kernel memory. The method then sends the reject notification to the client.

In one embodiment, a first attribute of a first rule corresponds to a first client process property. In another embodiment, a second attribute of a second rule corresponds to a second client process property. Each rule specified has one or more unique attributes. Each unique attribute corresponds to a unique client process property retrieved from kernel memory.

In some embodiments, the rules are part of a rule set. In this example, the rule set is part of a service call filter module and the service call filter module is a component of the appliance kernel.

In other embodiments, the method accesses the rule set to determine whether the internal service identified by the identifier is unprotected or protected (e.g., whether the rule set specifies or defines at least one rule for the identifier specified in the service call). 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 rule for the internal service specified in the service call.

In certain embodiments, the method forwarding the service call to the server if the internal service is unprotected, or if each attribute of at least one rule matches the corresponding client process property of the one or more client process properties.

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 advantage, 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.

One type of computing appliance (appliance) is a discrete hardware device with integrated software (e.g., firmware), specifically designed to provide a specific computing resource (e.g., access to one or more business services). Another type of appliance is a virtual appliance. A virtual appliance can be configured to provide similar functionality as a dedicated hardware appliance, but the virtual appliance is distributed (e.g., to customers), as a software virtual machine image in a hypervisor, or for a hypervisor-enabled device. In addition, a customer can deploy an appliance by integrating the software (e.g., operating system (OS) software) and the hardware of a computing device.

An appliance has exactly one combination of hardware, operating system, and application software (e.g., application software that is required to provide business services). Therefore, an appliance can be deployed and managed by customers without extensive Information Technology (IT) knowledge. Once deployed however, an appliance does not permit (and is 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, an appliance can be configured with 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 are generally not exposed to (or accessible by) users of the appliance or by other computing devices (e.g., external clients) outside the appliance.

Although internal services are not exposed to (nor accessible by) external clients, internal services are prone to security attacks from local and remote clients (e.g., local or remote client programs that execute on the appliance and/or users who have control of and/or access to the appliance). For example, a user with access to the appliance 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: (<NUM>) initiate a brute force attack (e.g., to gain sensitive information accessible to an internal service), (<NUM>) exploit security vulnerabilities of the internal service (e.g., by gaining root privilege using a reverse shell command), (<NUM>) initiate a Denial of Service (DoS) attack, and/or (<NUM>) initiate one or more of various other malicious attacks.

A firewall may be useful to secure internal services from external clients, but a firewall cannot prevent local client programs and/or users from accessing and attacking the internal services that are running on the appliance. Further, Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) do not secure internal services from local clients. Further still, 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 local clients is also not a feasible solution.

Disclosed herein are methods, systems, and processes to secure internal services in an appliance (e.g., in a single appliance deployment), by only permitting connection/service requests (e. g, connect calls, service calls, and the like) for internal services from certain clients (e.g., local 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 A Distributed Environment," 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.

<FIG> is a block diagram of an appliance, according to one embodiment. Appliance <NUM> is a computing device and includes a processor <NUM>, a memory <NUM>, and an operating system (OS) <NUM>. Appliance <NUM> is configured to secure one or more internal services executing on appliance <NUM>. Appliance <NUM> can be any of a variety of different computing devices, including a server, personal computing device, laptop computer, cellular phone, or the like. Appliance <NUM> can also execute (or host) any of a variety of different software programs (e.g., a client program, a server program, and the like) on one or more virtual machines.

As shown in <FIG>, appliance <NUM> implements a client program (e.g., client <NUM>) and a server program (e.g., server <NUM>). Client <NUM> executes a client process <NUM>. Client process <NUM> initiates service call <NUM> to server <NUM>. Client <NUM> and server <NUM> communicate with each other by exchanging messages through a common socket application programming interface (API). Service call <NUM> is one example of a type of message that can sent from client <NUM> to server <NUM>. For example, client <NUM> can execute client process <NUM> to request one or more internal services from server <NUM> by sending (or transmitting) service call <NUM> to server <NUM>. In this example, service call <NUM> is a connection (or service) request from client <NUM> to server <NUM> requesting one or more internal services from server <NUM>.

Server <NUM> provides internal services <NUM>(<NUM>)-(N). Internal services <NUM>(<NUM>)-(N) are computing services (e.g., web services, database services, message queues and the like) that are only provided to clients that are required for the appliance ecosystem (e.g., appliance <NUM>) to function. Appliance <NUM> can be configured to implement more than one server. Each such server can be implemented and configured to provide more than one internal service (e.g., internal services <NUM>(<NUM>) and <NUM>(<NUM>). In addition, different servers can be implemented and configured to provide different internal services (e.g., internal service <NUM>). It should be noted that the terms "internal service" and "server" can be used interchangeably in some embodiments. For example, the process instance of a database server can be referred to as a database service (e.g., an internal service), and the process instance of a message queue server can be referred to as a message queue service (e.g., another internal service).

Appliance <NUM> also includes kernel <NUM>. Kernel <NUM> is part of OS <NUM> that executes on appliance <NUM>. Kernel <NUM> manages input/output (I/O) requests from software (e.g., a data request, a data reply, and the like from client <NUM> and/or server <NUM>) and translates the I/O requests into data processing instructions (e.g., for a central processing unit (CPU) or other computing components of appliance <NUM>). Kernel <NUM> includes kernel memory <NUM> and a service call filter module <NUM>. Kernel memory <NUM> stores client process properties <NUM>(<NUM>)-(N). Service call filter module <NUM> sits in kernel <NUM> and includes a rule set <NUM>. Rule set <NUM> includes rules <NUM>(<NUM>)-(N) and identifiers <NUM>(<NUM>)-(N). In some embodiments, identifiers are service identifiers and include a port identifier and/or port number associated with an internal service. In addition to a port number, an identifier can also include a system address of a server that provides the required internal service (e.g., server properties).

<FIG> is a block diagram of an appliance that implements a service call filter module, according to one embodiment. Client <NUM> can be associated with a parent process. For example, parent process <NUM> can execute client process <NUM> on client <NUM> to initiate service call <NUM>. Client process <NUM> can then request server <NUM> to provide one or more internal. As shown in <FIG>, kernel <NUM> includes kernel memory <NUM>. Kernel memory <NUM> stores client process properties <NUM>(<NUM>)-(N). Client process properties <NUM>(<NUM>)-(N) are properties associated with client process <NUM> (and/or client <NUM>). In one embodiment, client process properties <NUM>(<NUM>)-(N) include but are not limited to: (<NUM>) client program name (e.g., a client program name that executes client process <NUM>), (<NUM>) parent process name (e.g., a parent process that executes client process <NUM>), (<NUM>) user or user group context associated with client process <NUM>, (<NUM>) terminal type of the client process (e.g., terminal type from where the client program is executed), and (<NUM>) one or more of various other client process properties.

Service call filter module <NUM> is also part of kernel <NUM>. Service call filter module <NUM> includes rule set <NUM>. Rule set <NUM> includes one or more rules (e.g., rules <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>)). Each internal service provided by the one or more servers executing on appliance <NUM> corresponds to (and is identified by) a single (and unique) identifier (e.g., internal service <NUM>(<NUM>) corresponds to identifier <NUM>(<NUM>)). An identifier includes a port number of the internal service/server, and can include a system address of the server providing the internal service.

Rule set <NUM> includes one or more rules that are specified and/or defined for a given internal service identified by a given identifier. As shown in <FIG>, a multiple rules can be specified and/or defined for a given identifier (e.g., each identifier can correspond to one or more rules). For example, rules <NUM>(<NUM>) and <NUM>(<NUM>) are specified and/or defined in rule set <NUM> for identifier <NUM>(<NUM>). Each rule includes one or more (unique) attributes that must be met, fulfilled, and/or matched by the client process properties of client process <NUM> before client <NUM> is provided access to an internal service that corresponds to the given identifier. In an appliance environment, a vendor can specify and/or define rule set <NUM>. In a non-appliance environment, a system administrator can specify and/or define rule set <NUM>.

<FIG> is a block diagram of a rule set with rules and attributes, according to one embodiment. Rule set <NUM> can include multiple rules (e.g., rules <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)). Each rule can specify and include one or more attributes. <FIG> is a block diagram of attributes and client process properties, according to one embodiment. As shown in <FIG>, each attribute specified in a rule is associated with an/or corresponds to a unique client process property. Therefore, access to internal service <NUM>(<NUM>) requires client process <NUM> to meet, fulfill, and/or match each attribute specified in rules <NUM>(<NUM>) and <NUM>(<NUM>) if identifier <NUM>(<NUM>) identifies internal service <NUM>(<NUM>) (e.g., using a port number associated with internal service <NUM>(<NUM>) and/or a system address of server <NUM>(<NUM>)).

As noted, identifiers can be port identifiers (e.g., each internal service has a unique port number). A port is an endpoint of communication in an OS. In appliance <NUM>, 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 <NUM> and server <NUM>). In other examples, an identifier can be any type of identifier (e.g., other than a port number, a port identifier, a service identifier, a system address, or any combination thereof) as long as the identifier uniquely identifies an internal service. However, it should also be noted that in one embodiment, the identifier specifies (or includes) a port number of the internal service, and optionally, a system address of the server that is providing the internal service. Therefore, the identifier can be used by service call filter module <NUM> to determine whether one or more rules have been specified/defined for the internal service identified by the identifier.

<FIG>, <FIG>, and <FIG> are block diagrams of a service filter module that intercepts a service call, according to one or more embodiments. In this example, service call filter module <NUM> intercepts service call <NUM> initiated by a client process. The client process (e.g., client process <NUM>) can be initiated by a user or by another process (e.g., parent process <NUM>) running in appliance <NUM> by executing a client program. Service call <NUM> is a request for an internal service (e.g., internal service <NUM>(<NUM>)) provided by server <NUM>). Service call <NUM> includes identifier <NUM>(<NUM>) that identifies internal service <NUM>(<NUM>).

In one embodiment, service call filter module <NUM> accesses rule set <NUM> to determine whether the internal service identified by the identifier is unprotected or protected (in the context of service call filter module <NUM>). In this example, the internal service is protected if rule set <NUM> specifies and/or defines at least one rule for the identifier specified in the service call. The internal service is unprotected if the rule set does not specifies and/or defines no rule for the identifier specified in the service call.

Therefore, by intercepting a service call (e.g., connect call <NUM>) that specifies an identifier, service call filter module <NUM> identifies an internal service identified by the identifier as well as one or more rules specified and/or defined for the internal service in rule set <NUM>. Further, by identifying the internal service (e.g., internal service <NUM>(<NUM>)) that is associated with the identifier (e.g., identifier <NUM>(<NUM>)), service call filter module <NUM> determines that rules <NUM>(<NUM>) and <NUM>(<NUM>) are applicable to internal service <NUM>(<NUM>). Service call filter module <NUM> then processes each attribute of the one or more rules to determine whether each attribute of each rule specified for a given identifier meets, fulfills, or matches the corresponding client process property associated with the client process that is retrieved from kernel memory.

In one embodiment, if no rule(s) are specified and/or defined in rule set <NUM> for the internal service identified by the identifier, service call filter module <NUM> forwards the service call to the server without accessing kernel memory to retrieve the client process properties because the lack of rule(s) indicates that the internal service is an unprotected internal service.

However, in another embodiment, if a rule (e.g., rule <NUM>(<NUM>)) is specified and/or defined in rule set <NUM> for an internal service identified by the identifier, service call filter module <NUM> processes each attribute of one or more rules specified using client process properties retrieved from kernel memory. If the processing indicates that the forwarding the service call is allowable (e.g., if each attribute in at least one rule specified for an internal service matches the corresponding client process property associated with the client process that initiates the service call), service filter module <NUM> forwards the service call to the server.

Kernel memory <NUM> stores multiple client process properties associated with the client process. For example, kernel memory <NUM> stores at least the following client process properties associated with the client process - a client program name, a parent process, a user context, a user group context, and/or a terminal type. Kernel memory <NUM> can also store various other possible client process properties in addition to the foregoing.

Therefore, if rules <NUM>(<NUM>) and <NUM>(<NUM>) are specified and/or defined for internal service <NUM>(<NUM>) identified by identifier <NUM>(<NUM>), service call filter module <NUM> access kernel memory <NUM> to determine whether client process <NUM> is associated with and/or corresponds to three unique client process properties (e.g., client process properties <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)) that match attributes <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>), respectively.

Service call filter module <NUM> processes attributes of rule(s) using client process properties by retrieving client process properties from kernel memory <NUM>. Because service call filter module <NUM> is a kernel component, service call filter module <NUM> has access to the contents of kernel memory <NUM>. Service call filter module <NUM> forwards the service call (e.g., connect call <NUM>) to the server if each attribute specified in one or more rules defined for a given internal service provided by the server matches at least one unique client process property retrieved from kernel memory <NUM>. Service call filter module <NUM> generates a reject notification if each attribute specified in a defined rule does not match at least one client process property retrieved from kernel memory <NUM>. Service call filter module <NUM> forwards the service call to the server without accessing kernel memory <NUM> (or performing attribute processing) if there is no rule that is specified and/or defined for the internal service identified by the identifier.

<FIG> is a service call authentication table, according to one or more embodiments. In one embodiment, service call <NUM>(<NUM>) can specify identifier <NUM>(<NUM>) (to identify and request access to a specific internal service). Service call filter module <NUM> intercepts service call <NUM>(<NUM>) from client <NUM> to server <NUM>(<NUM>). Service call filter module <NUM> then identifies the internal service that identified by identifier <NUM>(<NUM>) and determines whether rule set <NUM> specifies one or more rule(s) for the internal service. Because the internal service identified by service call <NUM>(<NUM>) is a protected internal service (e.g., one or more rules have been specified), service call filter module <NUM> accesses the one or more rules that are specified for the internal service to determine the attributes of each specified rule. In this case, the attributes of one such rule specified for the internal service identified by identifier <NUM>(<NUM>) in service call <NUM>(<NUM>) include a user context of "andrew," a user group context of "sales," a client program name of "Mongo," a parent process of "java," and a terminal type of "xterm.

Service call filter module <NUM> then accesses kernel memory <NUM> and retrieves the following client process properties of the client process - the user group name, the client program name, the parent process name, and the terminal type. Service call filter module <NUM> then processes the attributes with the retrieved client process properties. If each attribute of the specified rule(s) matches at least one client process property retrieved from kernel memory <NUM>, service call filter module <NUM> permits (or allows) service call <NUM>(<NUM>), and forwards service call <NUM>(<NUM>) to server <NUM>(<NUM>).

In another embodiment, service call <NUM>(<NUM>) can specify identifier <NUM>(<NUM>) (to identify and request access to a specific internal service). Service call filter module <NUM> intercepts service call <NUM>(<NUM>) from client <NUM> to server <NUM>(<NUM>). Service call filter module <NUM> then identifies the internal service that corresponds to identifier <NUM>(<NUM>) and determines whether one or more rules are specified for the internal service in rule set <NUM>. If at least one rule is not specified and/or defined for the internal service identified by identifier <NUM>(<NUM>), service call filter module <NUM> simply forwards service call <NUM>(<NUM>) to server <NUM>(<NUM>) without performing any additional processing (e.g., processing attributes and/or accessing kernel memory).

In certain embodiments, service call <NUM>(N) can specify identifier <NUM>(N) (to identify and request access to a specific internal service). Service call filter module <NUM> intercepts service call <NUM>(N) from client <NUM> to server <NUM>(N). Service call filter module <NUM> then identifies the internal service that corresponds to identifier <NUM>(N) and determines whether one or more rules are specified for the internal service in rule set <NUM>.

Kernel filter module <NUM> accesses rule set <NUM> and determines that the internal service is associated with one or more rules whose attributes require a client process to have a user context of "tina" a user group context of "marketing," a client program name of "mongo," a parent process of "java," and a terminal type of "vt100. " Service call filter module <NUM> accesses kernel memory <NUM> and retrieves the following client process properties of the client process - user name, user group, client program name, parent process, and the terminal type.

Service call filter module <NUM> then processes each attribute of each specified rule using the retrieved client process properties. Because each attribute specified in the rule(s) does not match at least one client process property retrieved from kernel memory <NUM> (e.g., user context "madelyn" does not match "tina", user group context "marketing" does not match "tech support," and terminal type "vt100" does not match "java"), service call filter module <NUM> sends a reject (or error) notification to client <NUM> and does not permit access to the internal service identified by identifier <NUM>(N) in service call <NUM>(N).

<FIG> is a flowchart that illustrates a process for forwarding a service call to a server, according to one embodiment. The process begins at <NUM> by intercepting a service call from a client (e.g., service call <NUM> initiated by client process <NUM>). At <NUM>, the process determines whether the identifier specified in the service call is associated with a protected internal service (e.g., whether one or more rule(s) are specified and/or defined for the identified internal service). If no rules are specified and/or defined for the internal service identified by the identifier, the process, at <NUM> permits the service call to be forwarded to the server without performing any additional processing.

However, if at least one rule is specified and/or defined for the internal service in rule set <NUM>, the process, at <NUM>, accesses kernel memory (of the appliance) and at <NUM>, processes attribute(s) of the specified rule(s) using client process properties retrieved from kernel memory (e.g., determines whether each attribute of at least one rule that is specified for the internal service matches a client process property retrieved from the kernel memory). At <NUM>, the process determines whether the processing indicates that the service call is permitted.

If each attribute of each rule that is specified for the internal service does not match a client process property, the process, at <NUM>, generates an error message (and sends the error message to the client initiating the service call). However, if each attribute of at least one rule that is specified for the internal service matches at least one client process property, the process ends at <NUM> by forwarding the service call to the server.

<FIG> is a flowchart that illustrates a process for processing rule attributes using client process properties, according to one embodiment. The process begins at <NUM> by intercepting a service call from a client. At <NUM>, the process determines whether the identifier (specified in the service call) is associated with an internal service that has a specified rule (or rules). If the internal service does not have a specified rule, the process, at <NUM>, permits the service call to be forwarded to the server. However, if at least one rule is specified and/or defined for the internal service, the process, at <NUM>, retrieves each rule specified for the internal service from a rule set (e.g., the rule set is part of and loaded into service call filter module <NUM>).

At <NUM>, the process retrieves client process properties from the kernel memory (e.g., by accessing kernel memory <NUM>). At <NUM>, the process processes each attribute of every rule specified using the client process properties. At <NUM>, the process determines whether the processing indicates that the service call is permitted. If each attribute of every rule that is specified for the internal service does not match at least one client process property, the process, at <NUM>, generates an error message (and sends the error message to the client initiating the service call). However, if each (unique) attribute of at least one rule that is specified and/or defined for the internal service (e.g., in rule set <NUM>) matches the corresponding client process property, the process ends at <NUM> by forwarding the service call to the server.

<FIG> is a flowchart that illustrates a process for determining whether to permit access to an internal service, according to one embodiment. The process begins at <NUM> by retrieving rule(s) from a rule set. At <NUM>, the process determines whether the internal service (e.g., identified by an identifier specified in a service call) is protected. If at least one rule is not specified and/or defined for the internal service, the process determines that the internal service is unprotected and at <NUM>, permits the service call to be forwarded to the server.

However, if at least one rule is specified and/or defined for the internal service in the rule set, the process determines that the internal service is protected, and at <NUM> retrieves client process properties from kernel memory. At <NUM>, the process performs processing (e.g., to determine whether each attribute of at least one rule specified and/or defined for the internal service matches the corresponding client process property retrieved from the kernel memory). At <NUM>, the process determines whether access to the internal service is permitted.

If each attribute of every rule that is specified and/or defined for the internal service does not match at least one client process property, the process, at <NUM>, sends a reject notification to the client. However, if each attribute of every rule that is specified and/or defined the internal service matches the corresponding client process property retrieved from kernel memory, the process ends at <NUM> by forwarding the service call to the server.

<FIG> is a flowchart that illustrates a process for securing internal services in an appliance, according to one embodiment. The process begins at <NUM> by intercepting a service call (e.g., a connect call, a service request, and/or a connection request) from a client (e.g., client <NUM>) for an internal service (e.g., internal service <NUM>(<NUM>)). At <NUM>, the process retrieves (or accesses) one or more rules (e.g., rules <NUM>(<NUM>) and <NUM>(<NUM>)) from a rule set (e.g., rule set <NUM>) specified and/or defined for the internal service. At <NUM>, the process retrieves client process properties (e.g., client process property <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>), and the like) from kernel memory (e.g., kernel memory <NUM>). At <NUM>, the process confirms that each attribute of each specified rule matches the corresponding client process property associated with the client process that initiates the service call. At <NUM>, the process ends by forwarding the service call to the server.

<FIG> is a block diagram of a computing system, illustrating how a service call filter module can be implemented in software, according to one embodiment. Computing system <NUM> represents any single or multi-processor computing device or system capable of executing computer-readable instructions. Computing system <NUM> can include, without limitation, one or more devices including workstations, personal computers, laptops, client-side terminals, servers, distributed computing systems, handheld devices, network appliances, storage controllers, and the like. Computing system <NUM> may include at least one processor <NUM> and a memory <NUM>. By executing the software that implements appliance <NUM>, computing system <NUM> becomes a computing device configured to secure internal services in an appliance.

Processor <NUM> generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. Processor <NUM> may receive instructions from a software application or module. These instructions may cause processor <NUM> to perform the functions of one or more of the embodiments described and/or illustrated herein. For example, processor <NUM> may perform and/or be a means for performing all or some of the operations, methods, or processes described and/or illustrated herein.

Memory <NUM> 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, or any other suitable memory device. Although not required, in certain embodiments computing system <NUM> may include both a volatile memory unit and a non-volatile storage device. In one example, program instructions implementing a service call filter module <NUM> may be loaded into memory <NUM>.

In certain embodiments, computing system <NUM> may also include one or more components or elements in addition to processor <NUM> and memory <NUM>. For example, as illustrated in <FIG>, computing system <NUM> may include a memory controller <NUM>, an Input/Output (I/O) controller <NUM>, and a communication interface <NUM>, each of which may be interconnected via a communication infrastructure <NUM>. Communication infrastructure <NUM> generally represents any type or form of infrastructure capable of facilitating communication between components of a computing device. Examples of communication infrastructure <NUM> include, without limitation, a communication bus (e.g., Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), PCI express (PCIe), or similar bus) and a network.

Memory controller <NUM> 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 <NUM>. For example, in certain embodiments memory controller <NUM> may control communication between processor <NUM>, memory <NUM>, and I/O controller <NUM> via communication infrastructure <NUM>. In certain embodiments, memory controller <NUM> 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 <NUM> 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 <NUM> may control or facilitate transfer of data between one or more elements of computing system <NUM>, such as processor <NUM>, memory <NUM>, communication interface <NUM>, display adapter <NUM>, input interface <NUM>, and storage interface <NUM>.

Communication interface <NUM> represents any type or form of communication device or adapter capable of facilitating communication between computing system <NUM> and one or more additional devices. For example, communication interface <NUM> may facilitate communication between appliance <NUM> and a private or public network including additional computing systems. Examples of communication interface <NUM> 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. Communication interface <NUM> may provide a direct connection to a remote server via a direct link to a network, such as the Internet. Communication interface <NUM> 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 <NUM> may also represent a host adapter configured to facilitate communication between computing system <NUM> 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) <NUM> 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 <NUM> may also allow computing system <NUM> to engage in distributed or remote computing. Communication interface <NUM> may receive instructions from a remote device or send instructions to a remote device for execution.

Computing system <NUM> may also include at least one display device <NUM> coupled to communication infrastructure <NUM> via a display adapter <NUM>. Display device <NUM> generally represents any type or form of device capable of visually displaying information forwarded by display adapter <NUM>. Similarly, display adapter <NUM> generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure <NUM> (or from a frame buffer, as known in the art) for display on display device <NUM>.

Computing system <NUM> may also include at least one input device <NUM> coupled to communication infrastructure <NUM> via an input interface <NUM>. Input device <NUM> generally represents any type or form of input device capable of providing input, either computer or human generated, to computing system <NUM>. Examples of input device <NUM> include, without limitation, a keyboard, a pointing device, a speech recognition device, or any other input device.

Computing system <NUM> may also include storage device <NUM> coupled to communication infrastructure <NUM> via a storage interface <NUM>. Storage device <NUM> generally represents any type or form of storage devices or mediums capable of storing data and/or other computer-readable instructions. Storage device <NUM> 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 <NUM> generally represents any type or form of interface or device for transferring and/or transmitting data between storage device <NUM>, and other components of computing system <NUM>. Storage device <NUM> 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 <NUM> may also include other similar structures or devices for allowing computer software, data, or other computer-readable instructions to be loaded into computing system <NUM> (e.g., to read and write software, data, or computer-readable information). Storage device <NUM> may also be a part of computing system <NUM> or may be separate devices accessed through other interface systems.

Other devices or subsystems may be connected to computing system <NUM>. All of the components and devices illustrated in <FIG> need not be present to practice the embodiments described and/or illustrated herein. The devices and subsystems referenced above may also be interconnected in different ways from that shown in <FIG>. Computing system <NUM> may also employ any number of software, firmware, and/or hardware configurations. For example, embodiments disclosed herein may be encoded as a computer program (also referred to as computer software, software applications, computer-readable instructions, or computer control logic) on a computer-readable storage medium. Examples of computer-readable storage media include magnetic-storage media (e.g., hard disk drives and floppy disks), optical-storage media (e.g., CD- or DVD-ROMs), electronic-storage media (e.g., solid-state drives and flash media), and the like. Such computer programs can also be transferred to computing system <NUM> for storage in memory via a network such as the Internet or upon a carrier medium.

The computer-readable medium containing the computer program may be loaded into computing system <NUM>. All or a portion of the computer program stored on the computer-readable medium may then be stored in memory <NUM> and/or various portions of storage device <NUM>. When executed by processor <NUM>, a computer program loaded into computing system <NUM> may cause processor <NUM> to perform and/or be a means for performing the functions of one or more of the embodiments described and/or illustrated herein. Alternatively, one or more of the embodiments described and/or illustrated herein may be implemented in firmware and/or hardware. Computing system <NUM> may be configured as an application specific integrated circuit (ASIC) adapted to implement one or more of the embodiments disclosed herein.

<FIG> is a block diagram of a networked system, illustrating how various computing devices can communicate via a network, according to one embodiment of the present disclosure. In certain embodiments, network-attached storage (NAS) devices may be configured to communicate with appliance <NUM> using various protocols, such as Network File System (NFS), Server Message Block (SMB), or Common Internet File System (CIFS).

Network <NUM> generally represents any type or form of computer network or architecture capable of facilitating communication between multiple computing devices. Network <NUM> may facilitate communication between appliance <NUM> and other systems. In certain embodiments, a communication interface, such as communication interface <NUM> in <FIG>, may be used to provide connectivity between appliance <NUM> and network <NUM>. It should be noted that the embodiments described and/or illustrated herein are not limited to the Internet or any particular network-based environment. For example, network <NUM> can be a Storage Area Network (SAN).

In at least one embodiment, all or a portion of one or more of the embodiments disclosed herein may be encoded as a computer program and loaded onto and executed by appliance <NUM>. In addition, all or a portion of one or more of the embodiments disclosed herein may also be encoded as a computer program, stored on appliance <NUM>, and distributed over network <NUM>.

In some examples, all or a portion of the computing devices in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG> may represent portions of a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

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, appliance <NUM> 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 service in one or more appliances.

Claim 1:
A method comprising:
intercepting a service call (<NUM>; <NUM>(<NUM>), <NUM>, <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>)) initiated by a client process (<NUM>) of a client (<NUM>) executing in a user space (<NUM>) of an appliance (<NUM>), wherein
the service call is intercepted by a service call filter module (<NUM>) executing in a kernel,
the service call is a request for an internal service of a plurality of internal services,
the internal service is provided by a server executing in another user space (<NUM>) of the appliance,
the service call comprises an identifier,
the identifier is one of a plurality of identifiers,
each identifier of the plurality of identifiers identifies a corresponding one of the plurality of services, and
the identifier identifies the internal service;
determining, by the service call filter module, whether one or more rules of a plurality of rules are specified for the internal service identified by the identifier, wherein
the service call filter module comprises a rule set,
the rule set is stored in a kernel memory (<NUM>) by virtue of being comprised in the service call filter module,
the rule set comprises the rules and the plurality of identifiers, and
the determining is performed by the service call filter module accessing the rule set using the identifier;
in response to a determination that the one or more rules are specified for the identifier,
retrieving one or more client process properties of a plurality of client process properties associated with the client process from a kernel memory (<NUM>),
processing one or more attributes of the one or more rules,
forwarding the service call to the server, if the processing indicates that the forwarding the service call is allowable, and
generating an error notification, if the processing indicates that the forwarding the service call is not allowable; and
in response to a determination that no rule is specified for the internal service identified by the identifier,
forwarding the service call to the server, wherein the forwarding the service call is performed without accessing the kernel memory.