Software – Kaushal Bansal, Uday MASUREKAR, Aravind Srinivasan, Shadab Shah, Serge Maskalik, Nicira Inc
Abstract for “Methods and apparatus for disseminating firewall rules”
“Some embodiments provide a novel way to specify firewall rules. The method allows you to specify for a firewall rule, a set or network nodes (also known as a set below), at which that firewall should be enforced. The method adds an additional tuple to a firewall rule (called the AppliedTo tuple). The AppliedTo tuple adds a list of enforcement points to which the firewall rule must be applied (i.e. enforced).
Background for “Methods and apparatus for disseminating firewall rules”
“Filter rule definitions typically include the five tuples source, destination, destination, port, service (or app) and an action value. Each tuple specifies the set of identifiers that will provide acceptable values for the particular tuple. This is true for all firewalls, both software-based and hardware-based. Hardware firewalls can protect both virtual and physical machines (VMs). There are a few drawbacks to hardware firewalls. Hardware firewalls can be seen as choke points, since they serve as one point of entry for all traffic. They also fail to provide security for the machines that are behind the choke points.
Software firewalls can either be used as a service node firewall (or VNIC (virtual networking interface card) level firewall. Service-node firewalls work in the same way as their hardware counterparts and provide firewalling capabilities at the borders. They have the same drawbacks as physical firewalls. They are choke points for network traffic and do not provide security for intra network traffic (i.e. for virtual machines behind the chokepoint). VNIC-level firewalls on the other side enforce security policies every packet leaves the VM’s VNIC. They can also provide security for intra-VM traffic. VNIC level firewalls are able to inspect traffic twice: once at the source and once at the destination.
The current VNIC-level firewall models apply all rules to all VMs within the datacenter. This means that there is a one to one mapping between the rule at the management level and the VNIC-level rule table. This one-to-one mapping reduces the number of rules that can be defined at management level. This approach also causes rule bloat at VNIC-level firewall table which in turn reduces the firewall engine’s processing speed. This method does not allow for control over whether rule processing occurs at destination or source for intra VM traffic. VNIC-level approaches do not provide multi-tenant solutions. This is because users must create multiple firewall contexts at the controller level in order to achieve multitenancy. There is an artful solution to firewall problems.
“Some embodiments provide a novel way to specify firewall rules. The method allows you to specify for a firewall rule, a set or network nodes (also known as a set below), at which that firewall should be enforced. The method adds an additional tuple to a firewall rule (also known as the AppliedTo tuple). The AppliedTo tuple adds a list of enforcement points (nodes), at which the firewall rule must be applied (i.e. enforced).
“In certain embodiments, the AppliedTo tuple may be configured to identify the set enforcement point identifiers using network constructs or compute constructs. Different embodiments offer different sets of network or compute constructs that can be used in the AppliedTo tuples for firewall rules. These constructs include (1) an individual or set VNICs/VMs, (2) compute constructs such as hosts and compute clusters that represent groups of hosts or VMs in a virtualized environment, and (3) network elements such as physical forwarding element (e.g. physical switches, physical routers), etc. ), logical forwarding element (e.g. logical switches and logical routers, among others). ), managed appliances, unmanaged appliances (e.g. third-party firewalls), and/or combination thereof. (4) Security groups formed by a group of one or more VNICs. VMs, hosts. Compute constructs. The AppliedTo tuple may be set to a wildcard value in some embodiments. This signifies that all possible values are available for the AppliedTo tuple, e.g. all VNICs.
“In certain embodiments, one of the compute constructs or network constructs can be specified in dynamic containers that can contain members (e.g. forwarding elements, hosts and VNICs). They can be dynamically removed or added to. The AppliedTo tuples in firewall rules can refer t such dynamically modified constructs. This allows the application of AppliedTo firewall rules (i.e. rules that include an AppliedTo tuple), to be dynamically adjusted for different locations within a given network by dynamically adjusting their membership.
“The method of certain embodiments distributes AppliedTo firewall rules among various firewall-enforcing device. Sometimes each firewall enforcement device is a firewall enforcement device. In other cases, each firewall enforcer device connects to one, two, or more firewall enforcement points (i.e. enforcement points) and/or enforces firewall rules for one or several firewall enforcement nosdes. The method may distribute to each firewall-enforcing devices only the AppliedTo firewall regulations that are relevant to them. The method in some embodiments removes the AppliedTo firewall rules not applicable to each device from the list of firewall rules it distributes to them.
“In some embodiments firewall-enforcing device include hosts on which multiple VMs run. These or other embodiments include network nodes that receive AppliedTo firewall rules. The method of certain embodiments does not resend a firewall rule to affected network nodes if the dynamic container used to define one or more firewall rules has been modified. Instead, it only sends the updated membership changes to the group defined by the dynamic containers. When a membership change to dynamic containers requires the addition or deletion of a firewall enforcement device, the method sends a firewall rule to the new firewall-enforcing devices.
“The method of certain embodiments allows the AppliedTo firewall Rules (1) to be specified using higher-level enforcement points identifiers and (2) to be distributed using lower-level enforcement points identifiers that can be deciphered or made easier by network nodes that have received the rules. Some embodiments distribute some AppliedTo firewall rules only to certain nodes that have the AppliedTo tuples. Other firewall rules are distributed to other nodes that do not have the AppliedTo tuples. In some embodiments, for example, the method distributes AppliedTo firewall Rules to hosts with one or several executing VMs. It also distributes non-AppliedTo firewall Rules to unmanaged third party devices that are unable to process AppliedTo rules. However, in other embodiments, the method distributes AppliedTo rules to any or all unmanaged appliances as these appliances may be able process AppliedTo rules.
“In some embodiments the network nodes that have received the AppliedTo firewall guidelines specify, based upon the received AppliedTo rules, one or several firewall rule tables for one, more or all of the data end nodes (e.g. VMs or VNICs, machines or other network elements that connect to the nodes). Some embodiments’ network nodes use the AppliedTo tuples from the received AppliedTo firewall to identify the data nodes that the network nodes must create firewall rule tables. In some embodiments, the specified firewall rule tables do not have the AppliedTo Tuples.
VNIC-level firewall rule tables are firewall tables that a host creates to protect the VNICs from VMs running on it. VNIC-level firewall rules tables contain only rules that are relevant to a specific VM’s VNIC. This set is smaller than the total number of rules the host has stored for all VMs executing there. Unnecessary rules in each VNIC-level firewall rule table slows down the processing of these rules, which are applied to each packet that is sent or received by the virtual machine’s firewall engine. The VNIC-level firewall table is smaller and therefore easier to search than a bigger, more complicated rule table.
“In some embodiments, the AppliedTo firewall can be specified for different VMs and different logical forwarding element without invoking these VMs. The method of some embodiments distributes AppliedTo firewall rules to any firewall-enforcing devices connected to data end nodes, even before a data node (e.g. a VM, physical machine) connects to a firewall enforcer device. The method of some embodiments distributes lower-level AppliedTo firewall rules to logical networks to a host that might be able to execute a VM. This is in addition to the VM being instantiated on the host. It is advantageous to push the AppliedTo firewall rules to such a host in advance. This allows the host to instantiate a VM, and to specify the VNIC or VM-level firewall tables for the VM, without having to interact with a controller.
The above-described methods offer several benefits. Using AppliedTos to define the enforcement points sets for firewall rules and rule filtering at multiple levels during management plane provisioning and deployment, it is possible to create concise firewall rule tables for data end nodes (e.g. VMs, VNICs etc.) using a non-bloated format. Non-bloated firewall rules tables allow for faster processing by firewall engine and thus better performance.
“AppliedTo tuples break down the one-to-1 mapping between the rule at the management level and the rule at the dataplane. This allows AppliedTo firewall rules to allow for a significant increase in the number of rules in the management plane. AppliedTo firewall rules provide a way to specify whether the rule is being applied at the source, destination, or both. This is in contrast to traditional firewall rule deployments, which do not provide effective controls for specifying the rule processing at destination or source. AppliedTo firewall rules can be applied to higher-level constructs and dynamic constructs. This allows firewall rules to be quickly specified for higher-level constructs, and to dynamically modify the group of elements to whom the rules apply by changing the membership of dynamic constructs. AppliedTo firewall rules are able to create firewall rules for a single tenant, or a single logical system for a tenant within a multi-tenant environment.
“The Summary that precedes is meant to be a quick introduction to certain embodiments of the invention. This summary is not intended to provide an overview or introduction of all the inventive subject matter in this document. The Detailed Description and the Drawings that follow will provide additional information about the embodiments as well as other embodiments. To fully understand the various embodiments in this document, it is necessary to read the Summary, the Detailed Description, and the Drawings. The illustrative details of the Summary, Detailed Description, and Drawings do not limit the claims.
“The following detailed description of invention contains many details, examples, as well as embodiments of the invention. It will be obvious to anyone skilled in the art that the invention does not have to be limited to the examples and details discussed. The invention can be used without these specific details and examples.
“Some embodiments provide a novel way to specify firewall rules. The method allows you to specify for a firewall rule a set or locations of network nodes (referred to below as a set enforcement points) where the firewall should be enforced. The method adds an additional tuple to a firewall rule (referred to as the AppliedTo tuple). The AppliedTo tuple adds a list of enforcement points to which the firewall rule must be applied (i.e. enforced).
“FIG. “FIG. The controller 100 allows AppliedTo firewalls can be configured by users or automated processes. The controller distributes the configured AppliedTo firewall rules 120 to multiple firewall-enforcing device 120 within a network (not illustrated) that is managed by the controller. FIG. FIG. 1 shows the components of the controller. They include a firewall rules configurator (105), a firewall data store 110 and a firewall distributor (115). The firewall rule configurator 105 configures AppliedTo firewall rules through interaction with users (through one to three user-interface modules or automated processes that are part firewall provisioning or network configuration). The firewall rule data storage 110 is where the configured AppliedTo rules are stored by this configurator 105.
“As shown at FIG. 1. The rule configurator (105) specifies each firewall rules 125 in the data store 110 in terms n-data tables for matching packets with firewall rules and an action to take when a packet matches the rule. The term “packet” is used in this document. The term “packet” is used to describe a collection or bits sent over a network in a specific format. A person of ordinary skill in art will be able to recognize that packet can be used to refer to different formats of bits that are sent across a network such as Ethernet frames and TCP segments.
FIG. 1. The six data tuples Source, Source Port and Destination are the six data tuples. Wildcard values can be used to indicate the applicability for all possible values. The AppliedTo identifier, which specifies the enforcement points at the firewall rule must be applied (i.e. enforced), is further explained below.
“Some embodiments specify the source and destination identifiers of L3-level firewall rules in terms IP addresses. L2 level firewall rules specify them in terms MAC addresses. One or more source and destination identifiers can be logical values. These values are used to identify a logical network. Other embodiments define all identifiers in the physical domains. Other embodiments define some identifiers in the logical domain while others are in the physical domain. Below are further descriptions of logical networks and logical constructs.
“The rule configurator105 ensures that all packets match at most one firewall rule. It also specifies at minimum one catchall firewall rule in data storage 110. This ensures that every packet matches at least one rule, even if it doesn’t match any other rules in the firewall table. In some cases, the rule configurator arranges the rules in data storage 110 according a precedence hierarchy. This ensures that higher priority rules are stored before lower priority ones. The fact that AppliedTo identifiers may be used to identify different enforcement nodes for different rules means that the rule configurator or a user acting through the rule configurator does not need to address precedence orders that firewall rules are to be sent at different enforcement nodes.
FIG. “In FIG. 1, along with other figures below, the source-destination port values for firewall rules are specified in wildcard values. This is not required for all firewall rules. The AppliedTo firewall rules may be defined with respect to the traditional port values (e.g. port 20, 80, 143 etc.). In the examples shown in the figures, the acronyms WS and AS stand for webserver and application server. These servers can be identified by their network addresses (e.g. IP addresses). These examples of firewall rules are intended to conceptually represent the idea of firewall rules, not actual firewall rules for a system.
“When a firewall engine (not illustrated) finds a firewall rule matching a packet, it performs the action specified by the rule?s Action identifier on the packet. In some cases, the Action identifier indicates that the packet should either be dropped or allowed through. Other acts can be used in combination with or instead of the drop and allow acts.
“The AppliedTo identifier, as mentioned above, specifies the enforcement points at which the firewall rules must be applied. The enforcement points may be defined as (1) VNICs or VMs, hosts or other compute constructs (e.g. compute clusters, datacenters etc.). (2) Network elements such as physical forwarding elements (e.g. physical switches, physical routers etc. ), logical forwarding element (e.g. logical switches and logical routers). ), unmanaged third party appliances (e.g. third party firewalls), and/or (3) security group that is formed by a combination of one or more VNICs. VMs, hosts. compute constructs and/or network constructions. The firewall configurator 105 allows AppliedTo identifiers be specified for both managed network devices as well as unmanaged network device. This provides a single interface that can manage all firewall rules defined for the network, which includes both managed devices and unmanaged devices.
“In some embodiments the AppliedTo tuple may also be set to a wildcard value. This signifies all possible values of the AppliedTo tuple, e.g. all VNICs. The AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller dynamically adjust firewall rules to different locations in a network by dynamically adjusting members of dynamically modifiable constructions.
“As shown at FIG. “As shown in FIG. 1, the controller distributes AppliedTo firewall rules 120 to various firewall enforcement devices 120 within the network. Some embodiments include hosts that host multiple VMs. Some embodiments also include hosts that host multiple VMs.
“In some embodiments, a controller distributes some AppliedTo firewall rule to certain nodes with the AppliedTo tuples. These tuples specify the sets and enforcement points associated with firewall rules. While distributing other firewall rules for other nodes that do not have the AppliedTo tuples, In some embodiments, for example, the method distributes AppliedTo firewall Rules to hosts with one or two executing VMs while distributing non-AppliedTo rules to one or several third party appliances that are unable to process AppliedTo rules. Other embodiments distribute AppliedTo firewall to any or all third-party appliances that can process AppliedTo rules. Still other embodiments distributed non-AppliedTo firewall Rules (i.e. firewall rules that do not contain AppliedTo data tuples to hosts that have one or more executing VMs). The AppliedTo data tuples are used by some embodiments of the method to identify hosts and VMs to whom it must forward firewall rules.
“Firewall-enforcing devices 120 can connect to one or several data end nodes 135, which may include different types of end nosdes in different embodiments. These data end nodes can be VMs or non-VM addressable ones (e.g. volume mounters (iSCSI, NFS, etc.). ), VM migrators, (e.g. vMotion module in the ESX hypervisor from VMware Inc.), hypervisor kernel network interface (e.g. vmknic .)).of VMware Inc). The firewall-enforcing device 120 can generate custom firewall data storages for each data end point or a group of data end points based on received AppliedTo firewall guidelines. The AppliedTo identifiers from the received AppliedTo firewall Rules are used by the firewall-enforcing device to determine which firewall rule is to be stored in each custom firewall storage.
“For example, a multi-VM host receiving the AppliedTo firewall Rules specifies multiple firewall rule table for multiple VNICs (based on the AppliedTo identifiers) of the VMs. In some embodiments, the VNIC-level firewall rules tables specified in certain embodiments do not have the AppliedTo table tuples. In some embodiments the VNIC-level firewall table only contains the rules applicable to the VNIC’s VM. This set of rules is smaller that the total number of rules the host stores for all VMs executing in it. Each rule in the VNIC level firewall rule table can be described in terms of six tuples. These are Source, Source Port and Destination. Destination Port is the Destination Port. Service identifiers are the Action identifiers.
“In some cases, firewall-enforcing device 120 can connect directly to data end nodes 135 or indirectly through one of several forwarding elements. The firewall-enforcing device 120 receives packets from and to the data nodes through their connections. In some embodiments, the enforcing device 120 compares the received packet attributes with firewall rules (e.g. with five data tuples: Source, Source Port and Destination, Destination Port and Service identifiers from the firewall rules). These packets are stored in custom firewall data storages created by the enforcing device for either the source or destination of the packet. The enforcing device then determines a firewall rule that corresponds to the packet and performs the action specified in the firewall rule.
“FIG. “FIG. This figure shows several examples of AppliedTo firewall Rules 125 that have been configured and stored by controller 100 in some embodiments. Each rule includes the five traditional tuples Source, Source Port and Destination.
“The AppliedTo tuples are illustrated in FIG. 2. include (1) compute constructs such as data center205 and compute cluster210; (2) network constructs such as physical router 215, and logical switch 220 and logical network225; (3) third-party appliance 230; (4) security group 235 and (5) wildcard entry 244.
In some embodiments, a “datacenter” is a location that hosts multiple hosts. Each host might be dedicated to one tenant, or multiple tenants. One host could be a non-virtualized dedicated machine or another might have multiple virtualized machines that run on it. A compute cluster is a grouping of hosts within a datacenter. FIG. FIG. 2 shows an example of a cluster consisting of two hosts 245 which each run two VMs 250. Some embodiments of a compute cluster are configured to support a specific set of tenants so that when a VM’s is instantiated or moved to one host, all or some of the data required for configuring that VM or configuring the VNIC level firewall data storage on that host is already available on that host.
“In some embodiments, each physically forwarding element (PFE), is a forwarding component that exists in the world. FIG. FIG. 2 shows the example of a physical router 215 for a PFE. A switch, router, firewall appliance, load balancer are all examples of a PFE. All such physical devices, including switches, routers and firewall appliances, can be included in some embodiments. You can have standalone hardware devices or hardware devices that are implemented on the physical NICs. Or software devices that run on dedicated hosts.
Software-forwarding elements will be referred to in this document as “physical forwarding elements” (PFEs) to differentiate them from logical elements. Logical forwarding elements are logical constructs that do not have a physical connection to the world. Software forwarding elements are called PFEs, because they are present and work in the physical world. Logical forwarding elements, on the other hand, are simply a logical representation or forwarding element that is presented in certain embodiments to a user.
“In certain embodiments, software forwarding components executed on different host devices (e.g. different computers) can be configured to implement different logic forwarding elements (LFEs), for different logical network of different tenants, users and departments. they share the same network and compute resources. Two software forwarding elements running on different host devices can perform L2 switch functionality, for example. Each software switch can implement in part two different logical l2 switches. Each logical l2 switch connects the VMs of one entity. Some embodiments provide L3 routing functionality through the software forwarding elements. These elements can be configured to implement different software L3 routers on other hosts. FIG. FIG. 2 shows a logical switch 220-as an example of a forwarding element. U.S. Patent Application Ser. No. No. No. No.
“A logical network can be defined as a network formed by one or more forwarding elements. FIG. FIG. 2 shows an example of a logic network 225, which is made up of one logical router (255) and three logical switch (260). Logical networks, which are similar to logical forwarding elements in certain embodiments, are a logical representation or network that is presented for a user or program. FIG. 2. The AppliedTo tuple may also be used to specify a physical network, which is made by one or more of the PFEs, as an enforcement point for a firewall policy.
Third-party appliances refer to forwarding elements that are not or minimally managed by the controllers in a network with multiple physical forwarding element that are managed (e.g. managed by controllers to implement one/more LFEs) In multi-tenant environments, for example, multiple controllers manage multiple forwarding elements at the edge of a network. They manage PFEs that are executed on hosts or connect directly to hosts. However, the connection between PFEs at the edge traverses through internal network fabric which includes third-party appliances, such as top-of-rack switch third parties. Some managed networks include managed non-edge forwarding and managed edge forwarding elements. These managed non-edge forwarding element perform functions that cannot be handled by managed edge forwarding elements. In some embodiments, these non-edge forwarding components are called service nodes.
“In certain embodiments, AppliedTo tuples may specify enforcement points in terms security groups. Security groups are formed by grouping VNICs, VMs hosts, compute constructs or network constructs. An example is that an AppliedTo firewall rule could be restricted (by the AppliedTo tuple), to a security group that specifies a specific compute cluster and a specific logical network that connects a tenant’s VMs. In some embodiments, users (e.g. network administrators) can specify security groups. In some embodiments, security groups can also be specified using an automated process. A wildcard value, as shown in entry 240 can also be used to specify an AppliedTo.tuple. In some embodiments, the wildcard value can be used to indicate all possible values of the AppliedTo tuple (e.g. all VNICs).
In some embodiments, the AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller dynamically adjust firewall rules for different locations within a network through dynamically adjusting members of dynamically modifiable constructions. One or more of the network constructs, compute constructs, and security groups can be described as dynamic containers. These containers can include members (e.g. forwarding elements, hosts VNICs, etc.). They can be dynamically removed or added to. A dynamic container is used to define one or more firewall rule AppliedTo tuples. However, some controllers do not resend firewall rules to affected network nodes. Instead, they only send the updated membership changes to the group defined by the dynamic containers.
“The controller in some embodiments permits the AppliedTo firewall rules (1) (e.g. by a network administrator, or an automated firewall configurator), to be specified in terms higher-level enforcement points identifiers. Then (2) to be distributed using lower-level enforcement points identifiers that can be deciphered or made easier decipherable by firewall-enforcing device. FIG. FIG. 3 shows one controller 300 and one host 350 that receives firewall rule distributions from the controller 300. The controller 300, as shown in the figure, includes a firewall rules configurator (305), a translation engine (310) and a publishing engine (315). It also contains a high-level rule storage 320 and a low level rule storage 325. FIG. FIG. 4. This illustrates various firewall rule tables created by the host 350 and controller 300 in certain embodiments of this invention.
The firewall rule configurator 305, which is similar to the firewall rule configuration 105, configures AppliedTo firewall rules through interaction with users (through one (or more) user-interface modules and/or automated processes. The firewall rule configurator 305 lets users and automated processes specify AppliedTo firewall rules using high-level enforcement points identifiers. These high-level enforcement points identifiers include network, compute and security constructs such as logical switches or routers, logical networks, physical networking, clusters of compute, datacenters, and logical switches.
“The configuration 305 stores the AppliedTo firewall rule it configures in the rule storage 320. FIG. FIG. 4 shows an example of a high level firewall rule table 405. The controller configures it and stores it in high-level data storage 325 of some embodiments. The high-level firewall table 405 contains multiple AppliedTo firewall Rules that are defined as high-level constructs such as a compute cluster or a datacenter.
“From rule data storage 320 the translation engine 310 retrieves AppliedTo firewall rules and converts high-level enforcement points identifiers in the AppliedTo tuples to lower-level enforcement points identifiers. In some embodiments, the translator engine converts compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. Network constructs (e.g. LFE identifiers and logical network identifiers) are also converted by the translation engine. VNIC values (VNIC IDs) and wildcard value. FIG. FIG. 4 shows an example of a low level firewall rule table (410). This table 410 has the same firewall rules as table 405, but each rule’s “AppliedTo” identifier specifies whether a wildcard value 412 is used or a list of VNICs that are associated with high-level identifiers.
“In so converting enforcement point identifiers the translation engine 310 ensures all AppliedTo firewall Rules are defined by low level enforcement point identifiers which can be deciphered and used by all firewall-enforcing device that receives the AppliedTo rules. The rule data storage 325 is where the translation engine stores all AppliedTo firewall rules it retrieves and converts them when necessary.
“In some embodiments, translation engine 310 may translate other parameters from firewall rules stored in the data storage 320 and then store the translated rules within the data storage 325. In some cases, the source and destination identifiers for firewall rules may be specified using high-level constructs such as containers like web server, app server or database server. Before the firewall rules are distributed to firewall-enforcing devices, they must be converted to lower-level identifications (e.g. specific IP addresses).
“One with ordinary skill in art will see that the translation engine works differently in different embodiments. In some embodiments, for example, the translation engine may not translate or not always translate high-level source identifiers to lower-level destination identifiers. Some embodiments leave this translation up to the firewall-enforcing device to do. In some embodiments, the translator engine doesn’t translate or always translate high-level AppliedTo identifiers from low-level AppliedTo identifiers. This is because the translation engine leaves this translation for all or some of the firewall enforcers devices to do. The translation of high-level firewall identifiers (e.g. AppliedTo, source, and destination identifiers) can be avoided. However, this reduces the number of rules that the controller distributes, and/or the size of the firewall rules, but it also requires the enforcing device to have the ability (e.g. the network state information), to do this translation.
“Even in certain embodiments where the controller distributes firewall rules with low AppliedTo identifiers, (e.g. with only VNIC or wildcard values), the translator 310 may not be used by the controller to unpack (i.e. convert) high-level AppliedTo identifiers, e.g. the high-level network and compute, and/or security constructions into low-level AppliedTo identifiers. Each high-level AppliedTo identifier such as each compute cluster identifier or LFE identifier etc. is included in this example. is an object containing a reference to a list VNIC values. The translation engine’s job in some embodiments is to populate VNIC lists of high-level identifier objects with wildcard references or identities of VNICs that belong to the high-level AppliedTo identifier (e.g. are members the compute cluster, LFE, etc.). Some embodiments use the rule configurator 305 to populate the VNIC list. In these cases, a translation engine will not be used for processing related to the high-level AppliedTo identifiers.
“For each data node that should receive AppliedTo firewall regulations, the publishing engine 315 (1) gathers host-level AppliedTo Rules 345 from the low level data storage 325 and (2) distributes these firewall rules to the data nodes. FIG. FIG. 3 shows how the publishing engine distributes firewall rules to multi-VM hosts. One of ordinary skill in art will recognize that publishing engine 315 is used for firewall rules distribution to other firewall-enforcing device in other embodiments.
“The publishing engine 315 identifies each host and retrieves from lower-level storage 325 the AppliedTo rules relevant to that host. The publishing engine may only send to each host the AppliedTo rules relevant to that host in some embodiments. In some embodiments, these AppliedTo rules include rules that pertain to VMs running on the host. FIG. FIG. 4 shows an example of a host level firewall rule table 415, which the publishing engine distributes in certain embodiments to a host. This table contains only the AppliedTo firewall rules applicable to the recipient host. This table is usually smaller than the AppliedTo tables 405 or 410 because it only contains rules applicable to one host.
“In some embodiments the rules that apply to each host also include the AppliedTo Rules that refer to VMs that could be instantiated on that host. The publishing engine 315 in some embodiments pushes the AppliedTo rules of a logical network to a host that is part of a compute cluster. This happens even before a VM belonging to that logical system is instantiated on that host. It is advantageous for hosts to push the AppliedTo firewall rules to such hosts ahead of time. This allows them to set up firewall rules for their VMs without having to interact with a controller. This configuration of firewall rules is known as “headless provisioning” because it doesn’t require interaction with a controller.
“In some embodiments, the publishing engines 315 collect the AppliedTo rules 345 from each host by examining higher-level AppliedTo storage 320. For instance, some embodiments do not define a lower-level AppliedTo data storage 325. These embodiments use the publishing engine 315 to scan the higher-level AppliedTo storage 320 in order to identify AppliedTo firewall regulations that are applicable to a particular host.
“Also. FIGS. 3 and 4 show how to create and distribute host-level AppliedTo rules sets to different hosts. However, an ordinary person of skill in the art will recognize that the publishing engine 315 also examines the controllers AppliedTo storage(s), to identify and publish firewall rules sets to non-host firewall enforcer devices (such third-party firewall devices). The publishing engine (1) does not publish non-AppliedTo rules (i.e. rules that do not have the AppliedTo identifier) in certain embodiments. (2) publishes only AppliedTo rules (i.e. rules with AppliedTo identifiers), to non-host firewall-enforcing device in other embodiments. (3) publishes non AppliedTo rules to non-host devices while publishing AppliedTo rules to other non?host firewall enforcers.
Each host 350 is equipped with a host controller interface 352, which receives and stores host-level rules in an host-level table 354. A VM firewall configurator is also available on each host. This configures the firewall rules to be used by each VM running on the host. It reads the host-level rule tables 354 and then stores them in a table. FIG. 3 shows the various embodiments. 3. The VM firewall configurator, a VNIC table configurator 356 generates one VNIC level firewall rule set for each VNIC. It does this by (1) using the AppliedTo data tuples 354 to identify firewall rules that apply to each VNIC, (2) retrieving those rules from the host-354 rules and (3) storing them in the VNIC?level firewall data storage 355 to be used for the VNIC. In some embodiments, each VM can have one VNIC. In other embodiments, however, each VM can have multiple VNICs.
“FIG. “FIG. The VNIC-level firewall rules table 420 does not contain the AppliedTo tuple. Instead, each firewall rule is specified in terms of five tuples (Source Port, Destination Port and Destination Port) as well as the action value. The VNIC-level firewall table only contains the rules that are relevant to a specific VNIC. This makes it smaller than the total number of rules the host has stored for all VMs running on it. This allows faster processing of firewall rules by firewall rule engines (not shown).
The above-described firewall distribution methods have many advantages. Using AppliedTos to define the enforcement points sets for firewall rules and rule filtering at multiple levels during dataplane provisioning, management-plane deployment and management-plane provisioning, these methods allow for concise and non-bloated firewall table specifications for data end nodes (e.g. VMs, VNICs etc.). The firewall rule engine will process non-bloated tables faster and thus deliver better performance.
“Section 1 below provides more details about some controllers in some embodiments. Section II provides more details about multi-VM hosts in some embodiments. Section III then describes some embodiments’ network control system. Section IV explains electronic devices used to implement some embodiments’ controllers and/or hosts.
“I. “I.
“FIG. FIG. 5 shows a controller 500 for some embodiments. Similar to controller 300 in FIG. 3. The controller 500, like the controller 300 of FIG. 3, can create AppliedTo firewall rules using higher-level enforcement points identifiers but distributes the AppliedTo rule using lower-level enforcement points identifiers. The controller 500 also includes a rule configurator 505, an engine for translating 510, and a publishing engine 515. It also has a high-level storage 320 and a low level storage 325. FIG. FIG. 5 shows the controller 500, which includes a user interface module (UI) 530, an automatic provisioning module 535 and a group definition data storage 540. There are also several enforcing device data storages 555 to 560 and 565.
The firewall rule configurator 505 configures AppliedTo firewall rules through interaction with users (e.g. network administrators) via the UI module 530. The configurator also configures AppliedTo firewall rules under the direction of automated provisioning 535. This module directs the configurator specify these rules when provisioning a physical or logical networking. When the controller 500 is part a network control system that manages logical networking in a multiuser (e.g. multi-tenant), hosted environment, the provisioning modules 535 and 505 in certain embodiments direct the configurator to specify at most some of the AppliedTo firewall laws when a logical net is being specified for only one user (e.g. for one tenant).
“The configurator 505 allows users to specify AppliedTo firewall rules using the provisioning module 535 or the UI module 535. These high-level enforcement points identifiers include network, compute and security constructs such as logical switches or logical routers. The rule data storage 320 is where the configurator 505 stores the AppliedTo firewall configurations it has made.
“From rule data storage 320 the translation engine 510 retrieves AppliedTo firewall rules and converts high-level enforcement points identifiers from the AppliedTo tuples to lower-level enforcement points identifiers. In some embodiments, the translator engine can convert compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. ), network constructs (e.g., LFE identifiers, logical network identifiers, etc. ), and security group (formed by one or several network or compute constructs into VNIC or wildcard values. The translation engine 510 converts enforcement point identifiers into AppliedTo firewall rule definitions. These enforcement point identifiers can then be deciphered and used by all firewall-enforcing device that receive the AppliedTo rules. The translation engine stores all AppliedTo firewall rules it retrieves and converts them when necessary in the low-level rule data storage 325.
The translation engine uses the group definition data storage 554 to convert high-level enforcement points identifiers, such as the network construct, compute construct and security groups, to low-level enforcement points identifiers, such as VNIC and wildcard value. These definitions can be stored by a user through the UI module 530 or the automated provisioning module 535.
These definitions can be statically defined in some embodiments. Other embodiments allow users or the provisioning module 535 to dynamically modify some or all the high-level group descriptions. In some embodiments, the AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller 500 dynamically adjust firewall rules to different locations in a network by dynamically adjusting members of dynamically modifiable constructions. The rule configurator can, in some embodiments, specify one or more compute constructs, network constructs or security groups as dynamic containers. These containers can have members (e.g. forwarding elements and hosts, VNICs etc.). They can be dynamically added to/or removed from them.”
“For enforcement points that can be defined by reference to dynamic or static groups, the translation engine510 (1) uses the group descriptions in the data store 540 to identify low-level identifications (e.g. the VNIC and wildcard value) associated with high-level high-level IDs. (2) Substitutes high-level high-level data identifiers with identified low-level IDs and (3) stores the resulting rules into the data storage 325. The translation engine updates the low level enforcement point identifiers for the affected firewall rules when a dynamic container is used to modify the AppliedTo tuple (s) of one or several firewall rules. The publishing engine 515 sends the updated membership information for the affected firewall rules, as described further below. This avoids having to send the affected firewall rules again to any firewall-enforcing device that has previously received them. The publishing engine will still send the affected firewall rule to the new firewall enforcement device if the member changes to a dynamic container that requires the addition of another firewall-enforcing tool.
“Like the translator 310 of controller 300, the translation engines 510 and 500 translate other parameters (e.g. source and destination identifiers), of firewall rules from data storage 320, before storing translated rules in data storage 325. The translation engine 510 (controller 500) also works differently in different embodiments, just like the translator engine 300. In some embodiments, for example, the translation engine may leave some or all the translations of high-level constructs in firewall rules of data storage 320 to certain or all firewall-enforcing device to do.
“Also in certain embodiments, even if the controller 500 distributes firewall rules with low AppliedTo identifiers, (e.g. with only VNIC or wildcard values), controller 500 doesn’t use the translation engine 510 for unpacking (i.e. to convert) high-level AppliedTo identifiers, e.g. the high-level network and/or security constructs into low-level AppliedTo identifiers. In some embodiments, the high-level AppliedTo identifiers are specified (e.g. each compute cluster identifier or LFE identifier). The object that refers to a list VNIC values. The job of the translation engine is to populate VNIC list of high-level identifier objects with wildcard references or identities of VNICs which are members the high-level AppliedTo identifier. Some embodiments use the rule configurator 305 to populate the VNIC list (e.g. by reference to group definitions in data storage 540). In these cases, a translation engine is not required for processing related to high-level AppliedTo identifiers.
“The publishing engine 515 collects enforcing device AppliedTo rules from low-level storage 325 and distributes them to the public. FIG. FIG. 5 shows that the publishing engine 515 contains a rule extractor 555 and a distribution engines 545. The rule extractor 550 identifies each firewall-enforcing devices and retrieves them from lower-level data storage 325. The rule extractor550 stores the retrieved firewall guidelines for each firewall-enforcing devices in the data storage (e.g. data storages 560, 555, and 565) that is maintained by the publishing engine for that particular firewall-enforcing machine.
“In some embodiments, rule extractor 55 only retrieves and stores the rules for each firewall-enforcing devices that are relevant to the firewall-enforcing devices. The enforcing devices data storages (e.g. data storages 555 and 560 that store firewall rules for each firewall enforcement device) are usually smaller than the high and low-level storages 320 or 325. This is because only AppliedTo rules pertain to the respective enforcing devices.
“In certain embodiments, the AppliedTo firewall regulations that apply to a firewall enforce device also include the AppliedTo rules that refer to data end nodes (e.g. VMs or VM VNICs), that are connected to the firewall enforce device. In some embodiments, rules that apply to each firewall-enforcing devices also include AppliedTo rules that are applicable to data end nodes connected to that firewall-enforcing apparatus. If a host is part of a compute cluster that implements a specific logical network, rule extractor 550 in some embodiments stores, within a data storage, the AppliedTo rules for that logical network. This happens even before a VM from the logical networks is instantiated on that host. It is advantageous to push the AppliedTo firewall rules to such a host in advance. This allows the host to set up firewall rules for the VM and not interact with a controller.
“In some embodiments, rule extractor 550 collects AppliedTo rules for each enforcing devices by examining the higher level AppliedTo data storage 320. For instance, some embodiments do not define a lower-level AppliedTo data storage 325. The rule extractor 550 searches the higher-level AppliedTo storage 320 for AppliedTo firewall rules applicable to a firewall enforcement device.
“FIG. “FIG.5” shows three data storages, 555, 560 and 565, that rule extractor550 maintains. Two of the data storages 555 & 560 are for hosts which execute firewall engines. These firewall engines serve as firewall enforcement devices for the VMs running on the hosts. Third party firewall appliances are stored in 565. The publishing engine (1) publishes non AppliedTo rules to non-host devices, (2) publishes AppliedTo rules to non-host devices, and (3) publishes non AppliedTo rules to non-host devices, while publishing AppliedTo rules to other nonhost devices.
According to some embodiments, the rule extraction removes the AppliedTo identifiers from all firewall rules to be published to nonhost firewall-enforcing device, before storing firewall rules in data storages (e.g. data storage 565) it maintains for these devices. Other embodiments store firewall rules along with their AppliedTo identifiers within the data storages (e.g. data storage 565) it maintains for non-host firewall enforcer devices. Another embodiment stores firewall rules without their AppliedTo identifiers on non-host firewall enforcement devices, while storing firewall rules with their AppliedTo identifiers on other non-host firewall-enforcing device.
“In some embodiments the distribution engine 545 from the publishing engine 515 pushes each firewall-enforcing devices (through a network), the firewall rules that are stored within the data storage that rule extractor maintains. Other embodiments pull firewall rules from the distribution engines. Other embodiments allow the distribution engine to push firewall rules to firewall-enforcing device, and also serve as a resource to pull firewall rule for other firewall enforcers.
“As stated above, the publishing engine distributes updates to AppliedTo enforcement points sets to firewall-enforcing device when a user modifies these sets dynamically. In some cases, such modifications can cause the translation engine to update firewall rules in lower-level data storage 325. This can lead to the rule extractor updating the AppliedTo fields of one or more rules in the enforcing device data storages it maintains. The rule extractor can create a new firewall policy for a newly defined enforcement point by updating the firewall rules in lower-level storages. This is a firewall-enforcing devices that are added to enforcement points for previously specified AppliedTo firewall rules in data storage 325. The distribution engine distributes the updated AppliedTo memberships, and/or new firewall rules (e.g. via push or pull actions), to the affected firewall enforcer devices.
“The operation and configuration of the controller 500 will be described in FIGS. 6-9. FIG. FIG. 6 shows a process 600 that controller 600’s translation engine 610 performs in certain embodiments. In some embodiments, the process 600 is executed each time a set AppliedTo firewall rules is stored in high-level storage 320. The process 600 can be performed in a batch fashion in some embodiments. In other embodiments, it is executed in real time upon receiving notification that the set of AppliedTo firewall rule has been stored in the high-level storage 320.
“As shown at FIG. “As shown in FIG. 6, the process receives at 605 the identity of the AppliedTo firewall rules that were added to the high level data storage. These rules can be described in terms of high-level AppliedTo identifiers such as network constructs and/or high-level compute constructs or security groups, or low-level AppliedTo identifiers such as VNIC and wildcard value.
“The process selects (at 610) one AppliedTo firewall rule from the received set. At 615, the process determines if the selected AppliedTo firewall rules has an AppliedTo identifier defined in terms at least one high level construct. At 615, the process converts the high-level AppliedTo identifier into a low-level Appliedto identifier. The process 600 uses the high-level group definitions stored in the group data storage 540 to convert high-level AppliedTo identifiers, such as the network construct, compute construct and security groups, to low-level AppliedTo identifiers, such as VNIC and wildcard value. The 600 uses the group definitions stored in the data store 540 to identify low-level AppliedTo identifiers. The process 615 may also translate other parameters (e.g. source and destination identifiers), of firewall rules (from data storage 320), before storing translated rules in data storage 325.
“At 620 the process checks whether it has reviewed all AppliedTo firewall rules within the set received at 605. If it has not, the process returns back to 610 to select another AppliedTo firewall rule and then performs operation 615 to convert this rule to a lower level rule, if necessary. It ends when it determines (at 620), that it has reviewed all AppliedTo firewall rules within the received set.
“In this way, process 600 converts high level compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. ), network constructs (e.g., LFE identifiers, logical network identifiers, etc. ), and security group (formed by one of more network or compute constructs in the AppliedTo firewall rules) into low-level identifiers. The translation process 600 converts the enforcement point identifiers into low-level enforcement points identifiers. This ensures that all AppliedTo firewall Rules are decoded by all firewall-enforcing device that receives the AppliedTo rules.
“FIG. “FIG.7” illustrates a 700-step process that the controller 500’s publishing engine 515 performs in certain embodiments. The process 700 may be performed every time a set AppliedTo firewall rules is stored in the low level data storage 325. This 700 process collects and distributes host level AppliedTo rules from low-level rule storage 325. The process 700 may be performed in a batch fashion in some embodiments. In other embodiments, it occurs in real time upon receiving a notification that a set AppliedTo firewall rules has been stored in the low-level rule data storage 325.
“As shown at FIG. 7), the process receives (at 705) the identity for the AppliedTo firewall rules that were added to the low level data storage. These rules may be specified using wildcard and VNIC values in some embodiments. At 710, the process selects one of the AppliedTo firewall rule in the set.
“Next, at 715 the process identifies every firewall-enforcing devices to which the selected rules applies. The value specified by the AppliedTo identifier for the selected rule is the basis of this rule extraction operation 715. In some embodiments, the rule extraction operation 550 examines every value in the AppliedTo identifier to determine the firewall-enforcing devices that are related to the examined value.
“In some embodiments, one firewall-enforcing devices is associated with any non-wildcard value. Other embodiments allow more than one firewall-enforcing gadget to be associated with an AppliedTo number. This is because multiple firewall-enforcing units may connect to the same data end node at different times. The publishing engine distributes a firewall policy for each data end node to every firewall-enforcing devices that might connect to the data node. If a host is part of a compute cluster that implements a specific logical network to which a particular VM connects, rule extraction operation 715 in some embodiments identifies the host as being connected to that particular VNIC. This is done before the VM is actually instantiated. These embodiments allow all hosts within a compute cluster to receive firewall rules for VMs connected via the logical network. This allows any host to configure the firewall rule table for a VM on the fly when the VM is instantiated.
“Next, for every firewall-enforcing devices that process 700 has identified at 715 the process adds (at720) the firewall rules selected at 710 into a firewall rule storage that the process keeps for that firewall-enforcing apparatus. These data storages for firewall-enforcing devices are usually smaller than the high and low-level storages 320, 325. This is because the enforcing data storages of each device contain only AppliedTo rules relevant to that device. The process 700 removes some of the AppliedTo rules from some firewall-enforcing device data storages. In the description of operation of the publishing engine 515, we have described the circumstances in which certain embodiments remove the AppliedTo identifier.
“At 725 the process checks whether it has reviewed all AppliedTo firewall rules within the set received at 705. If it has not, the process returns back to 710 to select another AppliedTo firewall rule and then performs operations 715-725 to this new AppliedTo firewall rules. Once the process has verified that all AppliedTo firewall rules have been reviewed, 700 pushes (through a networking) the firewall rules it found (at 720), to each firewall enforcer device. The process is ended after 730.
“While rule extraction and distribution process 700 has been described in detail, an ordinary skilled person in the art will recognize that this process is possible in other embodiments. Instead of pushing firewall rules to enforcing machines, the firewall-enforcing device pulls firewall rules from other embodiments.
“Also as previously mentioned, the process 700 in certain embodiments examines every AppliedTo value for each firewall rule to determine the storage location that should contain the firewall rule. The rule extraction operation 715, in some embodiments, examines each value of a low level firewall rule. It does this by associating one or more firewall enforcement devices with the high-level AppliedTo identifiers. To associate firewall rules with firewall-enforcing device, some embodiments use the AppliedTo identifiers in the high level data storage 320. However, certain embodiments push to firewall-enforcing equipment (1) the low-level AppliedTo identifiers stored in the high?level data storage 320 and (2) the low AppliedTo identifiers from the group definition storage 540 that correspond to high-level AppliedTo identifiers in the high?level data storage 320.
“Also the rule extraction operation 715 does not create and maintain data storages for each firewall-enforcing device individually. It aggregates the firewall rules of at least one group of related devices into one data storage in certain embodiments. In some embodiments, each host of a compute cluster receives the same set of firewall guidelines. This is because each host must be prepared to implement every logical switch implemented by any host in the cluster. In some embodiments, the process 700 creates one compute-cluster storage 555 which contains all firewall rules for all hosts within that cluster.
“FIG. “FIG. Process 800 updates the membership information for any affected firewall rules to all firewall-enforcing device(s) that are required to be notified of this membership change. When the membership changes to dynamic containers, the process 800 sends the affected firewall rules to a new firewall enforcement device or removes them from a firewall enforcement device.
“The 800 process will be explained using the example shown in FIG. 9. This example shows how AppliedTo firewall rules were created in the high-level and low-level storages 320, 325 based upon a dynamic security groups SGZ. The modification of the AppliedTo firewall policy in the low level storage 325 was done after a modification in the security group SGZ membership.
“As shown at FIG. 8 shows the 800 process. It starts when 805 is notified of the modification of a definition of a dynamic construction (e.g. a network construct or a security group that is used for defining the AppliedTo identifier for one or more AppliedTo Rules in the high-level storage 320. The definition of dynamic constructs can be stored in the group-definition storage according to some embodiments. A user can modify the definition at 805 of a dynamic construct through the UI module 530 or automated provisioning module 535 in some embodiments. In some embodiments, the group definition storage 540 can be used to call back to the translation engine (at 805) to notify it of any modification to a definition for a dynamic construct.
“At 810 the process identifies every high-level firewall rule affected by the modified definition of the dynamic construct. Because one dynamic construct can be used for multiple AppliedTo identifiers in multiple AppliedTo firewall rule in high-level data storage 320, this is called the 800 process. At 815, the process 800 selects one of eighteen high-level firewall rules. The process 800 updates at 820 the corresponding lower-level firewall rules in lower-level data storage 325 for the selected high-level firewall rule to reflect the updated definition. This update could result in one or more low level AppliedTo identifiers being added or removed from the corresponding lower firewall rule.
“FIG. “FIG. 9 is an illustration of an example that reflects adding a VNIC (called VNICN) to a low level firewall rule after this VNIC was added to the security group SGZ. This figure shows that VNIC N was added to the security group SGZ before a high-level security rule 905 was created. It refers to this group SGZ at time t2 and a low level rule 910 is created to replace the high-level 905 in low-level storage 325 (at the time t3). The VNIC N is added to the security group SGZ (at the time t4). At the time t5, the translation engine is notified of the change (at the time t5). The translation engine then identifies the high-level rule 905 as a rule that refers back to the modified security groups SGZ. Next, the engine modifies low-level 910 (at t6) to include VNICN in the AppliedTo ID of this rule.
“After 820 the process determines (at 825) whether it has reviewed all high-level firewall rule it identified at 810. (i.e. all the high level rules that refer to modified dynamic construct). If it does not, the process goes back to 815 to identify another high-level firewall rules and to update (820) the low level firewall rule that corresponds to the high-level firewall rule. Otherwise, the process will transition to 830.
“At 830 the process 800 reviews each lower level rule it has updated at 820 in order to update the Enforcing Device Data Storages (e.g. data storages 560, 565, and 555) that contain firewall rules for firewall-enforcing device. The process may identify the AppliedTo values that have been added or removed from each low-level firewall rule and then adds or subtracts these values from any enforcing device firewall rule (in an Enforcing Device Data Storage) that requires such updates. FIG. 9 illustrates an example. 9. The addition of VNIC N may require the addition to a lower-level firewall rule 910. Affected host is a host which executes or may execute VMs with the VNIC N. An affected compute cluster is a cluster that includes such a host.
“In this way, the process pushes (at 830), to one or more Enforcing Device Data Storages the updated membership change(s) to the lower-level firewall rules that is caused by the dynamic construct. Sometimes, the dynamic construct change and subsequent change in one or several low-level firewall rules may require a firewall rule be added or removed from one of the enforcing device data storages. In some cases, 800 will send the affected firewall rules to a new firewall enforcement device or remove the affected firewall rules from a firewall enforcement device when the dynamic container membership changes require the addition or deletion of a firewall enforcer device.
After updating the enforcing devices’ data storages at 830, process 800 pushes (at 835) updates to firewall-enforcing devices (through a network which had its data storage updated at 830). The process sends (at 835) a membership change to an enforcing gadget when it updates (at 830). The process also adds (at 805) a new firewall rule in an enforcing devices data storage. This process sends (at 855) the firewall rule. The modification is sent to the firewall-enforcing devices. It modifies its firewall rules, adds or subtracts firewall rules, and so forth. The process is ended after 835.
“A person of ordinary skill in art will be able to see that the update process 800 is implemented differently according to other embodiments. In some embodiments, the controller 500 does not keep lower-level rules in lower-level storage 325. These embodiments use the updated group definitions stored in the group -definition storage540 to update the firewall rules it stores in its enforcing data storages. This is when a dynamic construct’s membership has been modified in the store.
Summary for “Methods and apparatus for disseminating firewall rules”
“Filter rule definitions typically include the five tuples source, destination, destination, port, service (or app) and an action value. Each tuple specifies the set of identifiers that will provide acceptable values for the particular tuple. This is true for all firewalls, both software-based and hardware-based. Hardware firewalls can protect both virtual and physical machines (VMs). There are a few drawbacks to hardware firewalls. Hardware firewalls can be seen as choke points, since they serve as one point of entry for all traffic. They also fail to provide security for the machines that are behind the choke points.
Software firewalls can either be used as a service node firewall (or VNIC (virtual networking interface card) level firewall. Service-node firewalls work in the same way as their hardware counterparts and provide firewalling capabilities at the borders. They have the same drawbacks as physical firewalls. They are choke points for network traffic and do not provide security for intra network traffic (i.e. for virtual machines behind the chokepoint). VNIC-level firewalls on the other side enforce security policies every packet leaves the VM’s VNIC. They can also provide security for intra-VM traffic. VNIC level firewalls are able to inspect traffic twice: once at the source and once at the destination.
The current VNIC-level firewall models apply all rules to all VMs within the datacenter. This means that there is a one to one mapping between the rule at the management level and the VNIC-level rule table. This one-to-one mapping reduces the number of rules that can be defined at management level. This approach also causes rule bloat at VNIC-level firewall table which in turn reduces the firewall engine’s processing speed. This method does not allow for control over whether rule processing occurs at destination or source for intra VM traffic. VNIC-level approaches do not provide multi-tenant solutions. This is because users must create multiple firewall contexts at the controller level in order to achieve multitenancy. There is an artful solution to firewall problems.
“Some embodiments provide a novel way to specify firewall rules. The method allows you to specify for a firewall rule, a set or network nodes (also known as a set below), at which that firewall should be enforced. The method adds an additional tuple to a firewall rule (also known as the AppliedTo tuple). The AppliedTo tuple adds a list of enforcement points (nodes), at which the firewall rule must be applied (i.e. enforced).
“In certain embodiments, the AppliedTo tuple may be configured to identify the set enforcement point identifiers using network constructs or compute constructs. Different embodiments offer different sets of network or compute constructs that can be used in the AppliedTo tuples for firewall rules. These constructs include (1) an individual or set VNICs/VMs, (2) compute constructs such as hosts and compute clusters that represent groups of hosts or VMs in a virtualized environment, and (3) network elements such as physical forwarding element (e.g. physical switches, physical routers), etc. ), logical forwarding element (e.g. logical switches and logical routers, among others). ), managed appliances, unmanaged appliances (e.g. third-party firewalls), and/or combination thereof. (4) Security groups formed by a group of one or more VNICs. VMs, hosts. Compute constructs. The AppliedTo tuple may be set to a wildcard value in some embodiments. This signifies that all possible values are available for the AppliedTo tuple, e.g. all VNICs.
“In certain embodiments, one of the compute constructs or network constructs can be specified in dynamic containers that can contain members (e.g. forwarding elements, hosts and VNICs). They can be dynamically removed or added to. The AppliedTo tuples in firewall rules can refer t such dynamically modified constructs. This allows the application of AppliedTo firewall rules (i.e. rules that include an AppliedTo tuple), to be dynamically adjusted for different locations within a given network by dynamically adjusting their membership.
“The method of certain embodiments distributes AppliedTo firewall rules among various firewall-enforcing device. Sometimes each firewall enforcement device is a firewall enforcement device. In other cases, each firewall enforcer device connects to one, two, or more firewall enforcement points (i.e. enforcement points) and/or enforces firewall rules for one or several firewall enforcement nosdes. The method may distribute to each firewall-enforcing devices only the AppliedTo firewall regulations that are relevant to them. The method in some embodiments removes the AppliedTo firewall rules not applicable to each device from the list of firewall rules it distributes to them.
“In some embodiments firewall-enforcing device include hosts on which multiple VMs run. These or other embodiments include network nodes that receive AppliedTo firewall rules. The method of certain embodiments does not resend a firewall rule to affected network nodes if the dynamic container used to define one or more firewall rules has been modified. Instead, it only sends the updated membership changes to the group defined by the dynamic containers. When a membership change to dynamic containers requires the addition or deletion of a firewall enforcement device, the method sends a firewall rule to the new firewall-enforcing devices.
“The method of certain embodiments allows the AppliedTo firewall Rules (1) to be specified using higher-level enforcement points identifiers and (2) to be distributed using lower-level enforcement points identifiers that can be deciphered or made easier by network nodes that have received the rules. Some embodiments distribute some AppliedTo firewall rules only to certain nodes that have the AppliedTo tuples. Other firewall rules are distributed to other nodes that do not have the AppliedTo tuples. In some embodiments, for example, the method distributes AppliedTo firewall Rules to hosts with one or several executing VMs. It also distributes non-AppliedTo firewall Rules to unmanaged third party devices that are unable to process AppliedTo rules. However, in other embodiments, the method distributes AppliedTo rules to any or all unmanaged appliances as these appliances may be able process AppliedTo rules.
“In some embodiments the network nodes that have received the AppliedTo firewall guidelines specify, based upon the received AppliedTo rules, one or several firewall rule tables for one, more or all of the data end nodes (e.g. VMs or VNICs, machines or other network elements that connect to the nodes). Some embodiments’ network nodes use the AppliedTo tuples from the received AppliedTo firewall to identify the data nodes that the network nodes must create firewall rule tables. In some embodiments, the specified firewall rule tables do not have the AppliedTo Tuples.
VNIC-level firewall rule tables are firewall tables that a host creates to protect the VNICs from VMs running on it. VNIC-level firewall rules tables contain only rules that are relevant to a specific VM’s VNIC. This set is smaller than the total number of rules the host has stored for all VMs executing there. Unnecessary rules in each VNIC-level firewall rule table slows down the processing of these rules, which are applied to each packet that is sent or received by the virtual machine’s firewall engine. The VNIC-level firewall table is smaller and therefore easier to search than a bigger, more complicated rule table.
“In some embodiments, the AppliedTo firewall can be specified for different VMs and different logical forwarding element without invoking these VMs. The method of some embodiments distributes AppliedTo firewall rules to any firewall-enforcing devices connected to data end nodes, even before a data node (e.g. a VM, physical machine) connects to a firewall enforcer device. The method of some embodiments distributes lower-level AppliedTo firewall rules to logical networks to a host that might be able to execute a VM. This is in addition to the VM being instantiated on the host. It is advantageous to push the AppliedTo firewall rules to such a host in advance. This allows the host to instantiate a VM, and to specify the VNIC or VM-level firewall tables for the VM, without having to interact with a controller.
The above-described methods offer several benefits. Using AppliedTos to define the enforcement points sets for firewall rules and rule filtering at multiple levels during management plane provisioning and deployment, it is possible to create concise firewall rule tables for data end nodes (e.g. VMs, VNICs etc.) using a non-bloated format. Non-bloated firewall rules tables allow for faster processing by firewall engine and thus better performance.
“AppliedTo tuples break down the one-to-1 mapping between the rule at the management level and the rule at the dataplane. This allows AppliedTo firewall rules to allow for a significant increase in the number of rules in the management plane. AppliedTo firewall rules provide a way to specify whether the rule is being applied at the source, destination, or both. This is in contrast to traditional firewall rule deployments, which do not provide effective controls for specifying the rule processing at destination or source. AppliedTo firewall rules can be applied to higher-level constructs and dynamic constructs. This allows firewall rules to be quickly specified for higher-level constructs, and to dynamically modify the group of elements to whom the rules apply by changing the membership of dynamic constructs. AppliedTo firewall rules are able to create firewall rules for a single tenant, or a single logical system for a tenant within a multi-tenant environment.
“The Summary that precedes is meant to be a quick introduction to certain embodiments of the invention. This summary is not intended to provide an overview or introduction of all the inventive subject matter in this document. The Detailed Description and the Drawings that follow will provide additional information about the embodiments as well as other embodiments. To fully understand the various embodiments in this document, it is necessary to read the Summary, the Detailed Description, and the Drawings. The illustrative details of the Summary, Detailed Description, and Drawings do not limit the claims.
“The following detailed description of invention contains many details, examples, as well as embodiments of the invention. It will be obvious to anyone skilled in the art that the invention does not have to be limited to the examples and details discussed. The invention can be used without these specific details and examples.
“Some embodiments provide a novel way to specify firewall rules. The method allows you to specify for a firewall rule a set or locations of network nodes (referred to below as a set enforcement points) where the firewall should be enforced. The method adds an additional tuple to a firewall rule (referred to as the AppliedTo tuple). The AppliedTo tuple adds a list of enforcement points to which the firewall rule must be applied (i.e. enforced).
“FIG. “FIG. The controller 100 allows AppliedTo firewalls can be configured by users or automated processes. The controller distributes the configured AppliedTo firewall rules 120 to multiple firewall-enforcing device 120 within a network (not illustrated) that is managed by the controller. FIG. FIG. 1 shows the components of the controller. They include a firewall rules configurator (105), a firewall data store 110 and a firewall distributor (115). The firewall rule configurator 105 configures AppliedTo firewall rules through interaction with users (through one to three user-interface modules or automated processes that are part firewall provisioning or network configuration). The firewall rule data storage 110 is where the configured AppliedTo rules are stored by this configurator 105.
“As shown at FIG. 1. The rule configurator (105) specifies each firewall rules 125 in the data store 110 in terms n-data tables for matching packets with firewall rules and an action to take when a packet matches the rule. The term “packet” is used in this document. The term “packet” is used to describe a collection or bits sent over a network in a specific format. A person of ordinary skill in art will be able to recognize that packet can be used to refer to different formats of bits that are sent across a network such as Ethernet frames and TCP segments.
FIG. 1. The six data tuples Source, Source Port and Destination are the six data tuples. Wildcard values can be used to indicate the applicability for all possible values. The AppliedTo identifier, which specifies the enforcement points at the firewall rule must be applied (i.e. enforced), is further explained below.
“Some embodiments specify the source and destination identifiers of L3-level firewall rules in terms IP addresses. L2 level firewall rules specify them in terms MAC addresses. One or more source and destination identifiers can be logical values. These values are used to identify a logical network. Other embodiments define all identifiers in the physical domains. Other embodiments define some identifiers in the logical domain while others are in the physical domain. Below are further descriptions of logical networks and logical constructs.
“The rule configurator105 ensures that all packets match at most one firewall rule. It also specifies at minimum one catchall firewall rule in data storage 110. This ensures that every packet matches at least one rule, even if it doesn’t match any other rules in the firewall table. In some cases, the rule configurator arranges the rules in data storage 110 according a precedence hierarchy. This ensures that higher priority rules are stored before lower priority ones. The fact that AppliedTo identifiers may be used to identify different enforcement nodes for different rules means that the rule configurator or a user acting through the rule configurator does not need to address precedence orders that firewall rules are to be sent at different enforcement nodes.
FIG. “In FIG. 1, along with other figures below, the source-destination port values for firewall rules are specified in wildcard values. This is not required for all firewall rules. The AppliedTo firewall rules may be defined with respect to the traditional port values (e.g. port 20, 80, 143 etc.). In the examples shown in the figures, the acronyms WS and AS stand for webserver and application server. These servers can be identified by their network addresses (e.g. IP addresses). These examples of firewall rules are intended to conceptually represent the idea of firewall rules, not actual firewall rules for a system.
“When a firewall engine (not illustrated) finds a firewall rule matching a packet, it performs the action specified by the rule?s Action identifier on the packet. In some cases, the Action identifier indicates that the packet should either be dropped or allowed through. Other acts can be used in combination with or instead of the drop and allow acts.
“The AppliedTo identifier, as mentioned above, specifies the enforcement points at which the firewall rules must be applied. The enforcement points may be defined as (1) VNICs or VMs, hosts or other compute constructs (e.g. compute clusters, datacenters etc.). (2) Network elements such as physical forwarding elements (e.g. physical switches, physical routers etc. ), logical forwarding element (e.g. logical switches and logical routers). ), unmanaged third party appliances (e.g. third party firewalls), and/or (3) security group that is formed by a combination of one or more VNICs. VMs, hosts. compute constructs and/or network constructions. The firewall configurator 105 allows AppliedTo identifiers be specified for both managed network devices as well as unmanaged network device. This provides a single interface that can manage all firewall rules defined for the network, which includes both managed devices and unmanaged devices.
“In some embodiments the AppliedTo tuple may also be set to a wildcard value. This signifies all possible values of the AppliedTo tuple, e.g. all VNICs. The AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller dynamically adjust firewall rules to different locations in a network by dynamically adjusting members of dynamically modifiable constructions.
“As shown at FIG. “As shown in FIG. 1, the controller distributes AppliedTo firewall rules 120 to various firewall enforcement devices 120 within the network. Some embodiments include hosts that host multiple VMs. Some embodiments also include hosts that host multiple VMs.
“In some embodiments, a controller distributes some AppliedTo firewall rule to certain nodes with the AppliedTo tuples. These tuples specify the sets and enforcement points associated with firewall rules. While distributing other firewall rules for other nodes that do not have the AppliedTo tuples, In some embodiments, for example, the method distributes AppliedTo firewall Rules to hosts with one or two executing VMs while distributing non-AppliedTo rules to one or several third party appliances that are unable to process AppliedTo rules. Other embodiments distribute AppliedTo firewall to any or all third-party appliances that can process AppliedTo rules. Still other embodiments distributed non-AppliedTo firewall Rules (i.e. firewall rules that do not contain AppliedTo data tuples to hosts that have one or more executing VMs). The AppliedTo data tuples are used by some embodiments of the method to identify hosts and VMs to whom it must forward firewall rules.
“Firewall-enforcing devices 120 can connect to one or several data end nodes 135, which may include different types of end nosdes in different embodiments. These data end nodes can be VMs or non-VM addressable ones (e.g. volume mounters (iSCSI, NFS, etc.). ), VM migrators, (e.g. vMotion module in the ESX hypervisor from VMware Inc.), hypervisor kernel network interface (e.g. vmknic .)).of VMware Inc). The firewall-enforcing device 120 can generate custom firewall data storages for each data end point or a group of data end points based on received AppliedTo firewall guidelines. The AppliedTo identifiers from the received AppliedTo firewall Rules are used by the firewall-enforcing device to determine which firewall rule is to be stored in each custom firewall storage.
“For example, a multi-VM host receiving the AppliedTo firewall Rules specifies multiple firewall rule table for multiple VNICs (based on the AppliedTo identifiers) of the VMs. In some embodiments, the VNIC-level firewall rules tables specified in certain embodiments do not have the AppliedTo table tuples. In some embodiments the VNIC-level firewall table only contains the rules applicable to the VNIC’s VM. This set of rules is smaller that the total number of rules the host stores for all VMs executing in it. Each rule in the VNIC level firewall rule table can be described in terms of six tuples. These are Source, Source Port and Destination. Destination Port is the Destination Port. Service identifiers are the Action identifiers.
“In some cases, firewall-enforcing device 120 can connect directly to data end nodes 135 or indirectly through one of several forwarding elements. The firewall-enforcing device 120 receives packets from and to the data nodes through their connections. In some embodiments, the enforcing device 120 compares the received packet attributes with firewall rules (e.g. with five data tuples: Source, Source Port and Destination, Destination Port and Service identifiers from the firewall rules). These packets are stored in custom firewall data storages created by the enforcing device for either the source or destination of the packet. The enforcing device then determines a firewall rule that corresponds to the packet and performs the action specified in the firewall rule.
“FIG. “FIG. This figure shows several examples of AppliedTo firewall Rules 125 that have been configured and stored by controller 100 in some embodiments. Each rule includes the five traditional tuples Source, Source Port and Destination.
“The AppliedTo tuples are illustrated in FIG. 2. include (1) compute constructs such as data center205 and compute cluster210; (2) network constructs such as physical router 215, and logical switch 220 and logical network225; (3) third-party appliance 230; (4) security group 235 and (5) wildcard entry 244.
In some embodiments, a “datacenter” is a location that hosts multiple hosts. Each host might be dedicated to one tenant, or multiple tenants. One host could be a non-virtualized dedicated machine or another might have multiple virtualized machines that run on it. A compute cluster is a grouping of hosts within a datacenter. FIG. FIG. 2 shows an example of a cluster consisting of two hosts 245 which each run two VMs 250. Some embodiments of a compute cluster are configured to support a specific set of tenants so that when a VM’s is instantiated or moved to one host, all or some of the data required for configuring that VM or configuring the VNIC level firewall data storage on that host is already available on that host.
“In some embodiments, each physically forwarding element (PFE), is a forwarding component that exists in the world. FIG. FIG. 2 shows the example of a physical router 215 for a PFE. A switch, router, firewall appliance, load balancer are all examples of a PFE. All such physical devices, including switches, routers and firewall appliances, can be included in some embodiments. You can have standalone hardware devices or hardware devices that are implemented on the physical NICs. Or software devices that run on dedicated hosts.
Software-forwarding elements will be referred to in this document as “physical forwarding elements” (PFEs) to differentiate them from logical elements. Logical forwarding elements are logical constructs that do not have a physical connection to the world. Software forwarding elements are called PFEs, because they are present and work in the physical world. Logical forwarding elements, on the other hand, are simply a logical representation or forwarding element that is presented in certain embodiments to a user.
“In certain embodiments, software forwarding components executed on different host devices (e.g. different computers) can be configured to implement different logic forwarding elements (LFEs), for different logical network of different tenants, users and departments. they share the same network and compute resources. Two software forwarding elements running on different host devices can perform L2 switch functionality, for example. Each software switch can implement in part two different logical l2 switches. Each logical l2 switch connects the VMs of one entity. Some embodiments provide L3 routing functionality through the software forwarding elements. These elements can be configured to implement different software L3 routers on other hosts. FIG. FIG. 2 shows a logical switch 220-as an example of a forwarding element. U.S. Patent Application Ser. No. No. No. No.
“A logical network can be defined as a network formed by one or more forwarding elements. FIG. FIG. 2 shows an example of a logic network 225, which is made up of one logical router (255) and three logical switch (260). Logical networks, which are similar to logical forwarding elements in certain embodiments, are a logical representation or network that is presented for a user or program. FIG. 2. The AppliedTo tuple may also be used to specify a physical network, which is made by one or more of the PFEs, as an enforcement point for a firewall policy.
Third-party appliances refer to forwarding elements that are not or minimally managed by the controllers in a network with multiple physical forwarding element that are managed (e.g. managed by controllers to implement one/more LFEs) In multi-tenant environments, for example, multiple controllers manage multiple forwarding elements at the edge of a network. They manage PFEs that are executed on hosts or connect directly to hosts. However, the connection between PFEs at the edge traverses through internal network fabric which includes third-party appliances, such as top-of-rack switch third parties. Some managed networks include managed non-edge forwarding and managed edge forwarding elements. These managed non-edge forwarding element perform functions that cannot be handled by managed edge forwarding elements. In some embodiments, these non-edge forwarding components are called service nodes.
“In certain embodiments, AppliedTo tuples may specify enforcement points in terms security groups. Security groups are formed by grouping VNICs, VMs hosts, compute constructs or network constructs. An example is that an AppliedTo firewall rule could be restricted (by the AppliedTo tuple), to a security group that specifies a specific compute cluster and a specific logical network that connects a tenant’s VMs. In some embodiments, users (e.g. network administrators) can specify security groups. In some embodiments, security groups can also be specified using an automated process. A wildcard value, as shown in entry 240 can also be used to specify an AppliedTo.tuple. In some embodiments, the wildcard value can be used to indicate all possible values of the AppliedTo tuple (e.g. all VNICs).
In some embodiments, the AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller dynamically adjust firewall rules for different locations within a network through dynamically adjusting members of dynamically modifiable constructions. One or more of the network constructs, compute constructs, and security groups can be described as dynamic containers. These containers can include members (e.g. forwarding elements, hosts VNICs, etc.). They can be dynamically removed or added to. A dynamic container is used to define one or more firewall rule AppliedTo tuples. However, some controllers do not resend firewall rules to affected network nodes. Instead, they only send the updated membership changes to the group defined by the dynamic containers.
“The controller in some embodiments permits the AppliedTo firewall rules (1) (e.g. by a network administrator, or an automated firewall configurator), to be specified in terms higher-level enforcement points identifiers. Then (2) to be distributed using lower-level enforcement points identifiers that can be deciphered or made easier decipherable by firewall-enforcing device. FIG. FIG. 3 shows one controller 300 and one host 350 that receives firewall rule distributions from the controller 300. The controller 300, as shown in the figure, includes a firewall rules configurator (305), a translation engine (310) and a publishing engine (315). It also contains a high-level rule storage 320 and a low level rule storage 325. FIG. FIG. 4. This illustrates various firewall rule tables created by the host 350 and controller 300 in certain embodiments of this invention.
The firewall rule configurator 305, which is similar to the firewall rule configuration 105, configures AppliedTo firewall rules through interaction with users (through one (or more) user-interface modules and/or automated processes. The firewall rule configurator 305 lets users and automated processes specify AppliedTo firewall rules using high-level enforcement points identifiers. These high-level enforcement points identifiers include network, compute and security constructs such as logical switches or routers, logical networks, physical networking, clusters of compute, datacenters, and logical switches.
“The configuration 305 stores the AppliedTo firewall rule it configures in the rule storage 320. FIG. FIG. 4 shows an example of a high level firewall rule table 405. The controller configures it and stores it in high-level data storage 325 of some embodiments. The high-level firewall table 405 contains multiple AppliedTo firewall Rules that are defined as high-level constructs such as a compute cluster or a datacenter.
“From rule data storage 320 the translation engine 310 retrieves AppliedTo firewall rules and converts high-level enforcement points identifiers in the AppliedTo tuples to lower-level enforcement points identifiers. In some embodiments, the translator engine converts compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. Network constructs (e.g. LFE identifiers and logical network identifiers) are also converted by the translation engine. VNIC values (VNIC IDs) and wildcard value. FIG. FIG. 4 shows an example of a low level firewall rule table (410). This table 410 has the same firewall rules as table 405, but each rule’s “AppliedTo” identifier specifies whether a wildcard value 412 is used or a list of VNICs that are associated with high-level identifiers.
“In so converting enforcement point identifiers the translation engine 310 ensures all AppliedTo firewall Rules are defined by low level enforcement point identifiers which can be deciphered and used by all firewall-enforcing device that receives the AppliedTo rules. The rule data storage 325 is where the translation engine stores all AppliedTo firewall rules it retrieves and converts them when necessary.
“In some embodiments, translation engine 310 may translate other parameters from firewall rules stored in the data storage 320 and then store the translated rules within the data storage 325. In some cases, the source and destination identifiers for firewall rules may be specified using high-level constructs such as containers like web server, app server or database server. Before the firewall rules are distributed to firewall-enforcing devices, they must be converted to lower-level identifications (e.g. specific IP addresses).
“One with ordinary skill in art will see that the translation engine works differently in different embodiments. In some embodiments, for example, the translation engine may not translate or not always translate high-level source identifiers to lower-level destination identifiers. Some embodiments leave this translation up to the firewall-enforcing device to do. In some embodiments, the translator engine doesn’t translate or always translate high-level AppliedTo identifiers from low-level AppliedTo identifiers. This is because the translation engine leaves this translation for all or some of the firewall enforcers devices to do. The translation of high-level firewall identifiers (e.g. AppliedTo, source, and destination identifiers) can be avoided. However, this reduces the number of rules that the controller distributes, and/or the size of the firewall rules, but it also requires the enforcing device to have the ability (e.g. the network state information), to do this translation.
“Even in certain embodiments where the controller distributes firewall rules with low AppliedTo identifiers, (e.g. with only VNIC or wildcard values), the translator 310 may not be used by the controller to unpack (i.e. convert) high-level AppliedTo identifiers, e.g. the high-level network and compute, and/or security constructions into low-level AppliedTo identifiers. Each high-level AppliedTo identifier such as each compute cluster identifier or LFE identifier etc. is included in this example. is an object containing a reference to a list VNIC values. The translation engine’s job in some embodiments is to populate VNIC lists of high-level identifier objects with wildcard references or identities of VNICs that belong to the high-level AppliedTo identifier (e.g. are members the compute cluster, LFE, etc.). Some embodiments use the rule configurator 305 to populate the VNIC list. In these cases, a translation engine will not be used for processing related to the high-level AppliedTo identifiers.
“For each data node that should receive AppliedTo firewall regulations, the publishing engine 315 (1) gathers host-level AppliedTo Rules 345 from the low level data storage 325 and (2) distributes these firewall rules to the data nodes. FIG. FIG. 3 shows how the publishing engine distributes firewall rules to multi-VM hosts. One of ordinary skill in art will recognize that publishing engine 315 is used for firewall rules distribution to other firewall-enforcing device in other embodiments.
“The publishing engine 315 identifies each host and retrieves from lower-level storage 325 the AppliedTo rules relevant to that host. The publishing engine may only send to each host the AppliedTo rules relevant to that host in some embodiments. In some embodiments, these AppliedTo rules include rules that pertain to VMs running on the host. FIG. FIG. 4 shows an example of a host level firewall rule table 415, which the publishing engine distributes in certain embodiments to a host. This table contains only the AppliedTo firewall rules applicable to the recipient host. This table is usually smaller than the AppliedTo tables 405 or 410 because it only contains rules applicable to one host.
“In some embodiments the rules that apply to each host also include the AppliedTo Rules that refer to VMs that could be instantiated on that host. The publishing engine 315 in some embodiments pushes the AppliedTo rules of a logical network to a host that is part of a compute cluster. This happens even before a VM belonging to that logical system is instantiated on that host. It is advantageous for hosts to push the AppliedTo firewall rules to such hosts ahead of time. This allows them to set up firewall rules for their VMs without having to interact with a controller. This configuration of firewall rules is known as “headless provisioning” because it doesn’t require interaction with a controller.
“In some embodiments, the publishing engines 315 collect the AppliedTo rules 345 from each host by examining higher-level AppliedTo storage 320. For instance, some embodiments do not define a lower-level AppliedTo data storage 325. These embodiments use the publishing engine 315 to scan the higher-level AppliedTo storage 320 in order to identify AppliedTo firewall regulations that are applicable to a particular host.
“Also. FIGS. 3 and 4 show how to create and distribute host-level AppliedTo rules sets to different hosts. However, an ordinary person of skill in the art will recognize that the publishing engine 315 also examines the controllers AppliedTo storage(s), to identify and publish firewall rules sets to non-host firewall enforcer devices (such third-party firewall devices). The publishing engine (1) does not publish non-AppliedTo rules (i.e. rules that do not have the AppliedTo identifier) in certain embodiments. (2) publishes only AppliedTo rules (i.e. rules with AppliedTo identifiers), to non-host firewall-enforcing device in other embodiments. (3) publishes non AppliedTo rules to non-host devices while publishing AppliedTo rules to other non?host firewall enforcers.
Each host 350 is equipped with a host controller interface 352, which receives and stores host-level rules in an host-level table 354. A VM firewall configurator is also available on each host. This configures the firewall rules to be used by each VM running on the host. It reads the host-level rule tables 354 and then stores them in a table. FIG. 3 shows the various embodiments. 3. The VM firewall configurator, a VNIC table configurator 356 generates one VNIC level firewall rule set for each VNIC. It does this by (1) using the AppliedTo data tuples 354 to identify firewall rules that apply to each VNIC, (2) retrieving those rules from the host-354 rules and (3) storing them in the VNIC?level firewall data storage 355 to be used for the VNIC. In some embodiments, each VM can have one VNIC. In other embodiments, however, each VM can have multiple VNICs.
“FIG. “FIG. The VNIC-level firewall rules table 420 does not contain the AppliedTo tuple. Instead, each firewall rule is specified in terms of five tuples (Source Port, Destination Port and Destination Port) as well as the action value. The VNIC-level firewall table only contains the rules that are relevant to a specific VNIC. This makes it smaller than the total number of rules the host has stored for all VMs running on it. This allows faster processing of firewall rules by firewall rule engines (not shown).
The above-described firewall distribution methods have many advantages. Using AppliedTos to define the enforcement points sets for firewall rules and rule filtering at multiple levels during dataplane provisioning, management-plane deployment and management-plane provisioning, these methods allow for concise and non-bloated firewall table specifications for data end nodes (e.g. VMs, VNICs etc.). The firewall rule engine will process non-bloated tables faster and thus deliver better performance.
“Section 1 below provides more details about some controllers in some embodiments. Section II provides more details about multi-VM hosts in some embodiments. Section III then describes some embodiments’ network control system. Section IV explains electronic devices used to implement some embodiments’ controllers and/or hosts.
“I. “I.
“FIG. FIG. 5 shows a controller 500 for some embodiments. Similar to controller 300 in FIG. 3. The controller 500, like the controller 300 of FIG. 3, can create AppliedTo firewall rules using higher-level enforcement points identifiers but distributes the AppliedTo rule using lower-level enforcement points identifiers. The controller 500 also includes a rule configurator 505, an engine for translating 510, and a publishing engine 515. It also has a high-level storage 320 and a low level storage 325. FIG. FIG. 5 shows the controller 500, which includes a user interface module (UI) 530, an automatic provisioning module 535 and a group definition data storage 540. There are also several enforcing device data storages 555 to 560 and 565.
The firewall rule configurator 505 configures AppliedTo firewall rules through interaction with users (e.g. network administrators) via the UI module 530. The configurator also configures AppliedTo firewall rules under the direction of automated provisioning 535. This module directs the configurator specify these rules when provisioning a physical or logical networking. When the controller 500 is part a network control system that manages logical networking in a multiuser (e.g. multi-tenant), hosted environment, the provisioning modules 535 and 505 in certain embodiments direct the configurator to specify at most some of the AppliedTo firewall laws when a logical net is being specified for only one user (e.g. for one tenant).
“The configurator 505 allows users to specify AppliedTo firewall rules using the provisioning module 535 or the UI module 535. These high-level enforcement points identifiers include network, compute and security constructs such as logical switches or logical routers. The rule data storage 320 is where the configurator 505 stores the AppliedTo firewall configurations it has made.
“From rule data storage 320 the translation engine 510 retrieves AppliedTo firewall rules and converts high-level enforcement points identifiers from the AppliedTo tuples to lower-level enforcement points identifiers. In some embodiments, the translator engine can convert compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. ), network constructs (e.g., LFE identifiers, logical network identifiers, etc. ), and security group (formed by one or several network or compute constructs into VNIC or wildcard values. The translation engine 510 converts enforcement point identifiers into AppliedTo firewall rule definitions. These enforcement point identifiers can then be deciphered and used by all firewall-enforcing device that receive the AppliedTo rules. The translation engine stores all AppliedTo firewall rules it retrieves and converts them when necessary in the low-level rule data storage 325.
The translation engine uses the group definition data storage 554 to convert high-level enforcement points identifiers, such as the network construct, compute construct and security groups, to low-level enforcement points identifiers, such as VNIC and wildcard value. These definitions can be stored by a user through the UI module 530 or the automated provisioning module 535.
These definitions can be statically defined in some embodiments. Other embodiments allow users or the provisioning module 535 to dynamically modify some or all the high-level group descriptions. In some embodiments, the AppliedTo identifier can be used to refer to dynamically modifyable constructs. This allows the controller 500 dynamically adjust firewall rules to different locations in a network by dynamically adjusting members of dynamically modifiable constructions. The rule configurator can, in some embodiments, specify one or more compute constructs, network constructs or security groups as dynamic containers. These containers can have members (e.g. forwarding elements and hosts, VNICs etc.). They can be dynamically added to/or removed from them.”
“For enforcement points that can be defined by reference to dynamic or static groups, the translation engine510 (1) uses the group descriptions in the data store 540 to identify low-level identifications (e.g. the VNIC and wildcard value) associated with high-level high-level IDs. (2) Substitutes high-level high-level data identifiers with identified low-level IDs and (3) stores the resulting rules into the data storage 325. The translation engine updates the low level enforcement point identifiers for the affected firewall rules when a dynamic container is used to modify the AppliedTo tuple (s) of one or several firewall rules. The publishing engine 515 sends the updated membership information for the affected firewall rules, as described further below. This avoids having to send the affected firewall rules again to any firewall-enforcing device that has previously received them. The publishing engine will still send the affected firewall rule to the new firewall enforcement device if the member changes to a dynamic container that requires the addition of another firewall-enforcing tool.
“Like the translator 310 of controller 300, the translation engines 510 and 500 translate other parameters (e.g. source and destination identifiers), of firewall rules from data storage 320, before storing translated rules in data storage 325. The translation engine 510 (controller 500) also works differently in different embodiments, just like the translator engine 300. In some embodiments, for example, the translation engine may leave some or all the translations of high-level constructs in firewall rules of data storage 320 to certain or all firewall-enforcing device to do.
“Also in certain embodiments, even if the controller 500 distributes firewall rules with low AppliedTo identifiers, (e.g. with only VNIC or wildcard values), controller 500 doesn’t use the translation engine 510 for unpacking (i.e. to convert) high-level AppliedTo identifiers, e.g. the high-level network and/or security constructs into low-level AppliedTo identifiers. In some embodiments, the high-level AppliedTo identifiers are specified (e.g. each compute cluster identifier or LFE identifier). The object that refers to a list VNIC values. The job of the translation engine is to populate VNIC list of high-level identifier objects with wildcard references or identities of VNICs which are members the high-level AppliedTo identifier. Some embodiments use the rule configurator 305 to populate the VNIC list (e.g. by reference to group definitions in data storage 540). In these cases, a translation engine is not required for processing related to high-level AppliedTo identifiers.
“The publishing engine 515 collects enforcing device AppliedTo rules from low-level storage 325 and distributes them to the public. FIG. FIG. 5 shows that the publishing engine 515 contains a rule extractor 555 and a distribution engines 545. The rule extractor 550 identifies each firewall-enforcing devices and retrieves them from lower-level data storage 325. The rule extractor550 stores the retrieved firewall guidelines for each firewall-enforcing devices in the data storage (e.g. data storages 560, 555, and 565) that is maintained by the publishing engine for that particular firewall-enforcing machine.
“In some embodiments, rule extractor 55 only retrieves and stores the rules for each firewall-enforcing devices that are relevant to the firewall-enforcing devices. The enforcing devices data storages (e.g. data storages 555 and 560 that store firewall rules for each firewall enforcement device) are usually smaller than the high and low-level storages 320 or 325. This is because only AppliedTo rules pertain to the respective enforcing devices.
“In certain embodiments, the AppliedTo firewall regulations that apply to a firewall enforce device also include the AppliedTo rules that refer to data end nodes (e.g. VMs or VM VNICs), that are connected to the firewall enforce device. In some embodiments, rules that apply to each firewall-enforcing devices also include AppliedTo rules that are applicable to data end nodes connected to that firewall-enforcing apparatus. If a host is part of a compute cluster that implements a specific logical network, rule extractor 550 in some embodiments stores, within a data storage, the AppliedTo rules for that logical network. This happens even before a VM from the logical networks is instantiated on that host. It is advantageous to push the AppliedTo firewall rules to such a host in advance. This allows the host to set up firewall rules for the VM and not interact with a controller.
“In some embodiments, rule extractor 550 collects AppliedTo rules for each enforcing devices by examining the higher level AppliedTo data storage 320. For instance, some embodiments do not define a lower-level AppliedTo data storage 325. The rule extractor 550 searches the higher-level AppliedTo storage 320 for AppliedTo firewall rules applicable to a firewall enforcement device.
“FIG. “FIG.5” shows three data storages, 555, 560 and 565, that rule extractor550 maintains. Two of the data storages 555 & 560 are for hosts which execute firewall engines. These firewall engines serve as firewall enforcement devices for the VMs running on the hosts. Third party firewall appliances are stored in 565. The publishing engine (1) publishes non AppliedTo rules to non-host devices, (2) publishes AppliedTo rules to non-host devices, and (3) publishes non AppliedTo rules to non-host devices, while publishing AppliedTo rules to other nonhost devices.
According to some embodiments, the rule extraction removes the AppliedTo identifiers from all firewall rules to be published to nonhost firewall-enforcing device, before storing firewall rules in data storages (e.g. data storage 565) it maintains for these devices. Other embodiments store firewall rules along with their AppliedTo identifiers within the data storages (e.g. data storage 565) it maintains for non-host firewall enforcer devices. Another embodiment stores firewall rules without their AppliedTo identifiers on non-host firewall enforcement devices, while storing firewall rules with their AppliedTo identifiers on other non-host firewall-enforcing device.
“In some embodiments the distribution engine 545 from the publishing engine 515 pushes each firewall-enforcing devices (through a network), the firewall rules that are stored within the data storage that rule extractor maintains. Other embodiments pull firewall rules from the distribution engines. Other embodiments allow the distribution engine to push firewall rules to firewall-enforcing device, and also serve as a resource to pull firewall rule for other firewall enforcers.
“As stated above, the publishing engine distributes updates to AppliedTo enforcement points sets to firewall-enforcing device when a user modifies these sets dynamically. In some cases, such modifications can cause the translation engine to update firewall rules in lower-level data storage 325. This can lead to the rule extractor updating the AppliedTo fields of one or more rules in the enforcing device data storages it maintains. The rule extractor can create a new firewall policy for a newly defined enforcement point by updating the firewall rules in lower-level storages. This is a firewall-enforcing devices that are added to enforcement points for previously specified AppliedTo firewall rules in data storage 325. The distribution engine distributes the updated AppliedTo memberships, and/or new firewall rules (e.g. via push or pull actions), to the affected firewall enforcer devices.
“The operation and configuration of the controller 500 will be described in FIGS. 6-9. FIG. FIG. 6 shows a process 600 that controller 600’s translation engine 610 performs in certain embodiments. In some embodiments, the process 600 is executed each time a set AppliedTo firewall rules is stored in high-level storage 320. The process 600 can be performed in a batch fashion in some embodiments. In other embodiments, it is executed in real time upon receiving notification that the set of AppliedTo firewall rule has been stored in the high-level storage 320.
“As shown at FIG. “As shown in FIG. 6, the process receives at 605 the identity of the AppliedTo firewall rules that were added to the high level data storage. These rules can be described in terms of high-level AppliedTo identifiers such as network constructs and/or high-level compute constructs or security groups, or low-level AppliedTo identifiers such as VNIC and wildcard value.
“The process selects (at 610) one AppliedTo firewall rule from the received set. At 615, the process determines if the selected AppliedTo firewall rules has an AppliedTo identifier defined in terms at least one high level construct. At 615, the process converts the high-level AppliedTo identifier into a low-level Appliedto identifier. The process 600 uses the high-level group definitions stored in the group data storage 540 to convert high-level AppliedTo identifiers, such as the network construct, compute construct and security groups, to low-level AppliedTo identifiers, such as VNIC and wildcard value. The 600 uses the group definitions stored in the data store 540 to identify low-level AppliedTo identifiers. The process 615 may also translate other parameters (e.g. source and destination identifiers), of firewall rules (from data storage 320), before storing translated rules in data storage 325.
“At 620 the process checks whether it has reviewed all AppliedTo firewall rules within the set received at 605. If it has not, the process returns back to 610 to select another AppliedTo firewall rule and then performs operation 615 to convert this rule to a lower level rule, if necessary. It ends when it determines (at 620), that it has reviewed all AppliedTo firewall rules within the received set.
“In this way, process 600 converts high level compute constructs (e.g. datacenter identifiers and compute cluster identifiers), host identifiers etc. ), network constructs (e.g., LFE identifiers, logical network identifiers, etc. ), and security group (formed by one of more network or compute constructs in the AppliedTo firewall rules) into low-level identifiers. The translation process 600 converts the enforcement point identifiers into low-level enforcement points identifiers. This ensures that all AppliedTo firewall Rules are decoded by all firewall-enforcing device that receives the AppliedTo rules.
“FIG. “FIG.7” illustrates a 700-step process that the controller 500’s publishing engine 515 performs in certain embodiments. The process 700 may be performed every time a set AppliedTo firewall rules is stored in the low level data storage 325. This 700 process collects and distributes host level AppliedTo rules from low-level rule storage 325. The process 700 may be performed in a batch fashion in some embodiments. In other embodiments, it occurs in real time upon receiving a notification that a set AppliedTo firewall rules has been stored in the low-level rule data storage 325.
“As shown at FIG. 7), the process receives (at 705) the identity for the AppliedTo firewall rules that were added to the low level data storage. These rules may be specified using wildcard and VNIC values in some embodiments. At 710, the process selects one of the AppliedTo firewall rule in the set.
“Next, at 715 the process identifies every firewall-enforcing devices to which the selected rules applies. The value specified by the AppliedTo identifier for the selected rule is the basis of this rule extraction operation 715. In some embodiments, the rule extraction operation 550 examines every value in the AppliedTo identifier to determine the firewall-enforcing devices that are related to the examined value.
“In some embodiments, one firewall-enforcing devices is associated with any non-wildcard value. Other embodiments allow more than one firewall-enforcing gadget to be associated with an AppliedTo number. This is because multiple firewall-enforcing units may connect to the same data end node at different times. The publishing engine distributes a firewall policy for each data end node to every firewall-enforcing devices that might connect to the data node. If a host is part of a compute cluster that implements a specific logical network to which a particular VM connects, rule extraction operation 715 in some embodiments identifies the host as being connected to that particular VNIC. This is done before the VM is actually instantiated. These embodiments allow all hosts within a compute cluster to receive firewall rules for VMs connected via the logical network. This allows any host to configure the firewall rule table for a VM on the fly when the VM is instantiated.
“Next, for every firewall-enforcing devices that process 700 has identified at 715 the process adds (at720) the firewall rules selected at 710 into a firewall rule storage that the process keeps for that firewall-enforcing apparatus. These data storages for firewall-enforcing devices are usually smaller than the high and low-level storages 320, 325. This is because the enforcing data storages of each device contain only AppliedTo rules relevant to that device. The process 700 removes some of the AppliedTo rules from some firewall-enforcing device data storages. In the description of operation of the publishing engine 515, we have described the circumstances in which certain embodiments remove the AppliedTo identifier.
“At 725 the process checks whether it has reviewed all AppliedTo firewall rules within the set received at 705. If it has not, the process returns back to 710 to select another AppliedTo firewall rule and then performs operations 715-725 to this new AppliedTo firewall rules. Once the process has verified that all AppliedTo firewall rules have been reviewed, 700 pushes (through a networking) the firewall rules it found (at 720), to each firewall enforcer device. The process is ended after 730.
“While rule extraction and distribution process 700 has been described in detail, an ordinary skilled person in the art will recognize that this process is possible in other embodiments. Instead of pushing firewall rules to enforcing machines, the firewall-enforcing device pulls firewall rules from other embodiments.
“Also as previously mentioned, the process 700 in certain embodiments examines every AppliedTo value for each firewall rule to determine the storage location that should contain the firewall rule. The rule extraction operation 715, in some embodiments, examines each value of a low level firewall rule. It does this by associating one or more firewall enforcement devices with the high-level AppliedTo identifiers. To associate firewall rules with firewall-enforcing device, some embodiments use the AppliedTo identifiers in the high level data storage 320. However, certain embodiments push to firewall-enforcing equipment (1) the low-level AppliedTo identifiers stored in the high?level data storage 320 and (2) the low AppliedTo identifiers from the group definition storage 540 that correspond to high-level AppliedTo identifiers in the high?level data storage 320.
“Also the rule extraction operation 715 does not create and maintain data storages for each firewall-enforcing device individually. It aggregates the firewall rules of at least one group of related devices into one data storage in certain embodiments. In some embodiments, each host of a compute cluster receives the same set of firewall guidelines. This is because each host must be prepared to implement every logical switch implemented by any host in the cluster. In some embodiments, the process 700 creates one compute-cluster storage 555 which contains all firewall rules for all hosts within that cluster.
“FIG. “FIG. Process 800 updates the membership information for any affected firewall rules to all firewall-enforcing device(s) that are required to be notified of this membership change. When the membership changes to dynamic containers, the process 800 sends the affected firewall rules to a new firewall enforcement device or removes them from a firewall enforcement device.
“The 800 process will be explained using the example shown in FIG. 9. This example shows how AppliedTo firewall rules were created in the high-level and low-level storages 320, 325 based upon a dynamic security groups SGZ. The modification of the AppliedTo firewall policy in the low level storage 325 was done after a modification in the security group SGZ membership.
“As shown at FIG. 8 shows the 800 process. It starts when 805 is notified of the modification of a definition of a dynamic construction (e.g. a network construct or a security group that is used for defining the AppliedTo identifier for one or more AppliedTo Rules in the high-level storage 320. The definition of dynamic constructs can be stored in the group-definition storage according to some embodiments. A user can modify the definition at 805 of a dynamic construct through the UI module 530 or automated provisioning module 535 in some embodiments. In some embodiments, the group definition storage 540 can be used to call back to the translation engine (at 805) to notify it of any modification to a definition for a dynamic construct.
“At 810 the process identifies every high-level firewall rule affected by the modified definition of the dynamic construct. Because one dynamic construct can be used for multiple AppliedTo identifiers in multiple AppliedTo firewall rule in high-level data storage 320, this is called the 800 process. At 815, the process 800 selects one of eighteen high-level firewall rules. The process 800 updates at 820 the corresponding lower-level firewall rules in lower-level data storage 325 for the selected high-level firewall rule to reflect the updated definition. This update could result in one or more low level AppliedTo identifiers being added or removed from the corresponding lower firewall rule.
“FIG. “FIG. 9 is an illustration of an example that reflects adding a VNIC (called VNICN) to a low level firewall rule after this VNIC was added to the security group SGZ. This figure shows that VNIC N was added to the security group SGZ before a high-level security rule 905 was created. It refers to this group SGZ at time t2 and a low level rule 910 is created to replace the high-level 905 in low-level storage 325 (at the time t3). The VNIC N is added to the security group SGZ (at the time t4). At the time t5, the translation engine is notified of the change (at the time t5). The translation engine then identifies the high-level rule 905 as a rule that refers back to the modified security groups SGZ. Next, the engine modifies low-level 910 (at t6) to include VNICN in the AppliedTo ID of this rule.
“After 820 the process determines (at 825) whether it has reviewed all high-level firewall rule it identified at 810. (i.e. all the high level rules that refer to modified dynamic construct). If it does not, the process goes back to 815 to identify another high-level firewall rules and to update (820) the low level firewall rule that corresponds to the high-level firewall rule. Otherwise, the process will transition to 830.
“At 830 the process 800 reviews each lower level rule it has updated at 820 in order to update the Enforcing Device Data Storages (e.g. data storages 560, 565, and 555) that contain firewall rules for firewall-enforcing device. The process may identify the AppliedTo values that have been added or removed from each low-level firewall rule and then adds or subtracts these values from any enforcing device firewall rule (in an Enforcing Device Data Storage) that requires such updates. FIG. 9 illustrates an example. 9. The addition of VNIC N may require the addition to a lower-level firewall rule 910. Affected host is a host which executes or may execute VMs with the VNIC N. An affected compute cluster is a cluster that includes such a host.
“In this way, the process pushes (at 830), to one or more Enforcing Device Data Storages the updated membership change(s) to the lower-level firewall rules that is caused by the dynamic construct. Sometimes, the dynamic construct change and subsequent change in one or several low-level firewall rules may require a firewall rule be added or removed from one of the enforcing device data storages. In some cases, 800 will send the affected firewall rules to a new firewall enforcement device or remove the affected firewall rules from a firewall enforcement device when the dynamic container membership changes require the addition or deletion of a firewall enforcer device.
After updating the enforcing devices’ data storages at 830, process 800 pushes (at 835) updates to firewall-enforcing devices (through a network which had its data storage updated at 830). The process sends (at 835) a membership change to an enforcing gadget when it updates (at 830). The process also adds (at 805) a new firewall rule in an enforcing devices data storage. This process sends (at 855) the firewall rule. The modification is sent to the firewall-enforcing devices. It modifies its firewall rules, adds or subtracts firewall rules, and so forth. The process is ended after 835.
“A person of ordinary skill in art will be able to see that the update process 800 is implemented differently according to other embodiments. In some embodiments, the controller 500 does not keep lower-level rules in lower-level storage 325. These embodiments use the updated group definitions stored in the group -definition storage540 to update the firewall rules it stores in its enforcing data storages. This is when a dynamic construct’s membership has been modified in the store.
Click here to view the patent on Google Patents.