A facility is described that provides a firewall for dynamically activated resources. Examples of dynamically activated resources include, e.g., dynamically created ports, dynamically activated DCOM components, and so forth. In various embodiments, the facility provides an application programming interface (“API”) that enables applications, services, and other components to register themselves as providers of dynamically activated resources, such as RPC services. During the registration, each component provides an identifying name and a unique identifier, such as a universally unique identifier (“UUID”). As examples, an RPC service may provide a unique identifier and a DCOM component may provide a DCOM Application ID. The UUID is associated with one or more interfaces provided by the service providers. An administrator can then employ a user interface (“UI”) provided by the facility to configure the facility to enable one or more of the registered components yet disable other registered components as well as unregistered components. When a component is enabled, the facility does not filter out network traffic relating to that component. In contrast, when a component is disabled, the facility filters out network traffic relating to that component. The facility may be configured to apply a general filter rule, such as to prevent all RPC messages. When a registered component is enabled, an indication is added to a list of exceptions to the general filter rule. As an example, an exception to enable RPC messages having a particular UUID is added to the general filter rule of disabling all RPC messages. When a computing environment (e.g., operating system or hardware device) receives a message, an associated firewall determines whether the message is of a type that is to be generally filtered (e.g., RPC messages). If it is to be generally filtered, the firewall next requests the facility to determine whether the incoming message contains a UUID. If the incoming message contains a UUID that has been registered and is associated with an enabled component, the facility forwards the message to its destination. If the incoming message does not contain a UUID or contains a UUID that does not correspond to an enabled component, the message is filtered out.
In various embodiments, the facility receives the message at a known resource and determines a dynamically activated resource that should receive the message. This can be referred to as mapping an endpoint for the message. As an example, the facility may provide a “well-known” TCP/IP port at which it receives an initial RPC message destined to an enabled service provider, such as TCP/IP port 135. This port number is identified as “well known” because client components corresponding to the registered service provider may be programmed to transmit initial (or all) messages to this well-known port. Upon receiving the initial message at the well-known port, the facility determines whether a UUID indicated by the message corresponds to an enabled component. If that is the case, the facility determines an actual port number that the corresponding component employs to receive messages. The facility can forward the received message to the determined port number. The facility may also communicate the determined port number to the client component that sent the initial message so that the client component can send a message to the determined port number. In various embodiments, the client component may send subsequent messages either to the well-known port or to the determined port number. When subsequent messages are received by the facility at the well-known port, the facility can forward the received messages to the determined port number.
In various embodiments, the facility can be used to enable or disable identified RPC interfaces or methods provided by a component instead of all RPC interfaces or methods provided by the component. The facility can enable identified RPC interfaces or methods by associating a UUID with each such interface or method and then selectively forwarding only messages containing enabled UUIDs. Thus, a subset of interfaces or methods provided by a component can be enabled or disabled by an administrator.
In various embodiments, the facility can be employed to selectively enable DCOM components. A DCOM message generally contains a globally unique identifier (“GUID”). A GUID generally corresponds to multiple UUIDs. By enabling the multiple UUIDs corresponding to a GUID, the facility can be used to enable some DCOM components but disable others.
Thus, the facility enables an administrator to reduce the attack surface available to malware by selectively enabling dynamically activated resources. Instead of enabling all RPCs, for example, the administrator can selectively enable some of them.
Turning now to the figures,
Client and server computing devices can be various types of general purpose or specifically configured computers. Components of the computers may include, but are not limited to, a processing unit, a system primary memory, a storage device, a network adapter or interface, a display, and one or more input and output devices. A computer typically includes a variety of computer-readable media that are operable with the storage device. Computer-readable media can be any available media that can be accessed by the computer and include both volatile and nonvolatile media and removable and nonremovable media.
The computer may operate in a networked environment using logical connections to one or more remote computers. A remote computer may be a personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above in relation to the computer. A logical connection can be made via a local area network (LAN) or a wide area network (WAN), but may also include other networks. Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets, and the Internet. The computer can be connected to a network through a network interface or adapter, such as to a wired or wireless network.
The computer is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the facility. The computing system should not be interpreted as having any dependency or requirement relating to any one or a combination of the illustrated components.
The facility is operational with numerous other general purpose or special purpose computing systems or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the facility include, but are not limited to, personal computers, server computers, handheld or laptop devices, cellular telephones, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The facility may be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The facility may also be employed in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media, including memory storage devices.
Other components operate in kernel mode, and are illustrated below line 302. TCP driver 314 and UDP driver 316 operate with IP driver 318 to process TCP/IP and UDP over IP messages. HTTP driver 324 processes HTTP messages. A named pipes component 326 processes named pipes, which enable two processes that are executing on the same or different computers to communicate with each other. RPCs can employ named pipes and HTTP to send and receive information.
Filtering platform 320 and firewall 322 operate in both user mode and kernel mode, and are illustrated in
While
In various embodiments, the facility can use TCP/IP to transport RPC messages in lieu of (or in addition to) HTTP messages. In such a case the facility can place the UUID inside the TCP/IP messages.
At block 704, the routine receives a name of the component that is to be registered, one or more UUIDs associated with the component, and a port number at which the component will listen for messages. The name of the component can be a human-readable name that is used in a UI associated with the facility to identify a component. The received UUIDs correspond to the UUIDs associated with the identified component that identify messages that should not be filtered out when the component is enabled. The received port number is the TCP/IP port at which the component will receive messages. The endpoint mapper may forward messages it receives at a well known port to the identified TCP/IP port number.
In various embodiments, the component does not register the port number when it is registered. Instead, the component may register the port number when it starts, such as after the computer is rebooted.
At block 706, the routine determines whether the received name or UUID is already registered. If the received name or UUID is already registered, the routine continues at block 708. Otherwise, the routine continues at block 710.
At block 708, the routine reports an error to the user and then continues at block 712, where it returns.
At block 710, the routine stores the received name, UUIDs, and port number. As an example, the routine may store the received information in a UUID table, such as in a registry or other storage. The routine then continues at block 712, where it returns.
At block 804, the routine receives a name of a component. The name can be the name indicated in the UUID table, and may be provided in the UI described above.
At block 806, the routine determines whether the received name is registered. The routine may make this determination by evaluating the received name against the UUID table. If the received name is registered, the routine continues at block 810. Otherwise, the routine continues at block 808.
At block 808, the routine may report an error to the user. As an example, the routine may indicate that the received name does not correspond to a registered component. The routine then continues at block 812, where it returns.
At block 810, the routine adds the UUID corresponding to the received name to a list of exceptions. Then, when the facility receives a message that is indicated to be forwarded to the component by specifying the component's UUID, the facility will not filter out the message. On the other hand, when the facility receives a message that does not correspond to an enabled component's UUID, the facility filters out the message.
Although the illustrated routine is described in terms of receiving an indication of a component name, the routine could equally receive one or more UUIDs to add to the exceptions list. In such a case, the routine would instead determine whether the UUID corresponds to an enabled component and add the UUID to the exceptions list if that is the case. Thus, even when a component is enabled, only a subset of its UUIDs may be enabled and so only messages containing the UUIDs listed in the exceptions list would be forwarded.
At block 904, the routine receives a message at a well known port. As an example, the routine may receive the message at TCP/IP port 135.
At block 905, the routine optionally authenticates the received message. As an example, the routine may determine whether messages from a particular TCP/IP address or range of addresses are to be accepted or ignored. Alternatively, the routine may determine whether a destination TCP/IP address or range of addresses indicated in the received message is valid.
At block 906, the routine determines whether the message indicates a UUID. When the message indicates a UUID, the routine continues at block 908. Otherwise, the routine continues at block 916.
At block 908, the routine determines whether the indicated UUID is registered and enabled. If the indicated UUID is registered and enabled, the routine continues at block 910. Otherwise, the routine continues at block 916.
At block 910, the routine determines the port number corresponding to the indicated UUID. As an example, the routine may determine the correspondence by evaluating the UUID table.
At block 912, the routine forwards the received message to the determined TCP/IP port. The service provider can then process the message.
At block 914, the routine optionally returns the determined TCP/IP port number to the client component that sent the message so that the client component can send subsequent messages directly to the determined TCP/IP port number. The routine then continues at block 918, where it returns.
At block 916, the routine optionally reports an error to the user. The routine then continues at block 918, where it returns.
Those skilled in the art will appreciate that the steps shown in
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.