Patent Application
20100100616
The present invention relates to a method and apparatus for controlling traffic between different entities on a network.
We define “network entity” in this matter as including various types of entity such as;—
physical entities comprising IP addresses, ports, devices, remote or local networks or sub networks VLANs, and
logical entities such as tunnels (of various protocols such as IPSec (Internet Protocol Security (IETF)). and GRE (Generic Router Encapsulation) tunnels), internet, items relating to the time of receipt of the packet, or the application (e.g. TCP/UDP IP services such as HTTP, SMTP), or number of bytes in the packet or the rate of receipt of traffic etc.
A router which applies network traffic policy (such as a firewall router) applies a defined network traffic policy between different physical addresses, e.g. different IP addresses of devices on a network. Effectively, it will only allow access between addresses in accordance with a policy The addresses are usually gathered together in a so-called zone. Thus, for example, all computers which are used by a sales team may be in a “sales zone” and all computer which are used by an accounts department are in a “accounts zone” and these two zones will have access to different IP addresses, i.e. to different computers or servers which hold, for example, information relevant to their job.
The different network entities between which network policy could be enforced needed to be configured as part of the policy.
Hitherto, policy configuration is complex and a policy needs to be modified to support new types of network entities. Thus each time there is a change of entity in the network, it is necessary to modify the policy.
Security devices can enforce policy on the traffic between different network points. Basic devices enforce this policy purely on the source or destination network addressing information contained within packets. More complex devices can enforce the policy based on the source or destination location where a location can be defined in terms of physical port, VLAN, tunnel endpoint, etc. In such devices, policy configuration is complex.
There are also problems in dealing with packets of data from VLANs or tunnel which are encapsulated. Present systems only inspect the encapsulated packet.
The present invention provides, according to another aspect, a method and apparatus for controlling traffic between different entities on a network in accordance with a predetermined policy in which the network policy is applied to each layer within a layered tunnel model.
The present invention provides, according to a one aspect, a method and apparatus for controlling traffic between different entities on a network in which packets of received data are inspected, and if encapsulated, are decapsulated layer by layer and, after each layer is decapsulated, the packet is checked to determine if the packet is to be forwarded or otherwise acted upon or discarded.
Thus the packet of data is thoroughly inspected before forwarding which improves security.
Preferably the apparatus of the invention further provides:—
(a) means to receive packets of data,
(b) means to inspect each packet and discard the packet if it is determined that it should not be forwarded or otherwise acted upon,
(c) means to determine if the packet is encapsulated,
(d) means to decapsulate the inspected packet if it is encapsulated,
(e) means to repeat steps (b), (c) and (d) on the decapsulated packet, and
(f) means to forward or otherwise act upon the packet if it is not encapsulated.
Preferably the method of the invention further provides:—
(a) receiving packets of data,
(b) inspecting each packet and discarding the packet if it is determined that it should not be forwarded or otherwise acted upon,
(c) determining if the packet is encapsulated,
(d) decapsulating the inspected packet if it is encapsulated,
(e) repeating steps (b), (c) and (d) on the decapsulated packet, and
(f) forwarding or otherwise acting upon the packet if it is not encapsulated.
Generally, prior arrangements only inspect the packet when it has been completely decapsulated by examining the data. It will be understood that by the use of an iteration (by repeating steps (b), (c) and (d)) of this aspect of the invention, by the decapsulation of the packet and inspecting the packet at each decapsulation, greater security can be provided to avoid forwarding packets containing unwanted data.
Preferably the packet can be encapsulated before forwarding.
The step (b) may include inspecting the packet to see if it matches a previous session (i.e. have packets of that type already been inspected and found not to be of a type to be discarded) and if so passing to step (c), and if not,
(b1) calculating a forwarding path for the packet
(b2) associating the packet with a logical forwarding zone,
(b3) determining if the policy allows the packet to be forwarded or otherwise acted upon,
(b4) if the policy does not allow the packet to be forwarded or otherwise acted upon, discarding the packet,
(b5) if the policy does allow the packet to be forwarded or otherwise acted upon, creating a new session entry and proceeding to step (c).
According to another aspect, the invention provides a computer program on a computer readable medium for controlling traffic between different entities on a network in which packets of received data are inspected, and if encapsulated, are decapsulated layer by layer and, after each layer is decapsulated, the packet is inspected to determine if the packet is to be acted upon or discarded, said program comprising
program means for receiving packets of data,
(b) program means for inspecting each packet and discarding the packet if it is determined that it should not be acted upon,
(c) program means for determining if the packet is encapsulated,
(d) program means for decapsulating the inspected packet if it is encapsulated,
(e) program means to repeat steps (b), (c) and (d) on the decapsulated packet, and
(f) program means to act upon the packet.
According to another aspect of the present invention, there is provided a method and apparatus for controlling traffic between different entities on a network in accordance with a predetermined policy, the policy being applied to network traffic being passed between logical security zones, wherein each logical security zone can be simultaneously associated with one or more types of network entity.
An advantage of this arrangement is that it allows great flexibility in adding to the logical security zone without changing the policies. For example, if there is a zone which we can refer to as the “sales department” zone, it is possible to add a remote sales departments via a VLAN or tunnel simply by adding the VLAN or tunnel attributes to the “sales department” zone without amending the policy and so the remote sales force will then have the same access to the network as the local sales force.
Also the use of, for example time in defining the zone has uses not provided by the prior arrangements. For example, one might define an “office zone” which is defined, inter alia, by a time of 8 am to 6 pm. This would mean that the routing of packets would be barred at any time outside those hours which would be an added security feature. This does not need a change of or definition in policy.
According to a preferred arrangement of this aspect of the invention there is provided a method and apparatus in which there is provided
(a) defining a plurality of zones,
(b) defining a plurality of actions or policies,
(c) receiving packets of data,
(d) inspecting the packet and device configuration to determine its source zone and its destination zone
(e) applying the policy relating to the relevant source and destination zones to determine from that policy whether the packet should be acted upon or discarded, characterised in that at least one of said source and destination zones includes both physical entities and logical entities,
Thus, different types of network entities (i.e. physical and logical entities) can be introduced to a zone without a change of policy.
Preferably, said at least one of said source and destination zones includes items relating to the time of receipt of the packet, or the application (e.g. TCP/UDP IP services such as HTTP, SMTP), or number of bytes in the packet.
Thus, the source and destination zone may comprise logical security zones which can be associated with any group of network locations, including physical ports, VLANs, or logical tunnel termination points for IPSec, GRE, PPTP (Point to Point Tunnelling Protocol) or L2TP (Layer 2 Tunnelling Protocol)
Preferably the network policy is classified in terms of source and destination logical security zone.
Thus a logical security zone's network locations may also be updated without modifying actual policy configuration, simplifying the task of migrating to a new network configuration. Future network locations can be added to a logical security zone without changing the policy configuration.
Any traffic between network locations that are within the same logical security zone is not subject to policy further simplifying policy configuration for trusted network locations.
Preferred embodiments of the invention will now be described by way of example and with reference to the accompanying drawings in which:—
We will now describe a preferred embodiment of the invention with reference to
As is shown in
The router 10 is connected via a tunnel 23 in internet 11 to a remote network 24 via a router 25, a hub 26.
Each network of course will comprise a plurality of devices such as work-stations, personal computers, and connections for laptop computers, printers, and the like.
The router 10, if it is a router/firewall, includes means to control traffic between the different entities on the network.
In essence, the various entities (which may not necessarily be physical devices, as will become clear later) are divided into logical security zones. One logical security zone is illustrated at 30 in
As is also clear from
Thus the router will examine any data packet from a source logical security zone and determine in accordance with the relevant policy rule whether that source packet can be passed to a destination logical security zone.
The network router includes an apparatus for controlling traffic (i.e. the data packets) between different entities on a network which will hereafter be referred to as a network traffic controller. The network traffic controller may be provided in the form of software operating on a router or the like or may be in the form of a dedicated device. The network traffic controller enforces traffic control between networks segments contain policy enforcement points which are typically associated with the physical network interfaces or VLANs of the product.
The network traffic controller uses the concept of a virtual security zone from which a data packet is received on to which it is to be sent. This is a
logical policy enforcement point that not only can be associated with physical entities such as physical network interfaces or VLANs, but can also be associated with logical entities such as tunnel termination points, such as the end of a GRE, IPSec, PPTP or L2TP tunnel and a security zone can be associated with a list of ranges of IP addresses. Any traffic received which is not within this network protection range results in a security event indicating spoofed network traffic.
A logical entity of a security zone can be associated with inbound and outbound traffic rates. This can be used to limit the rate of traffic over a VPN tunnel to minimise network queuing and hence reduce network latency for latency sensitive traffic.
Intrusion detection can be enabled or disabled on a security zone. Any sort of network attack can be detected on not only physical ports but any supported VPN tunnel. For trusted security zones, intrusion detection can be disabled to improve performance.
For convenience, each security zone is associated with a name (Alan, Beryl, Finance Department, Sales Department). A policy rule can use the security zone's name as the source or destination of packets for policy enforcement between security zones.
If physical ports, VLANs or logical tunnel termination points are associated with the same security zone, there is no network traffic restriction between these entities.
As examples, any combination of the following can be used to classify a packet into a logical security zone for use within policy as a source or destination zone:
A. Physical entities:—
For reception, the source IP address of the packet is matched to the zone's IP address set
Automatic retrieval through a name resolution protocol, such as DNS, of the user to network address mapping
B. Logical entities:—
The following describes how logical zoning is configured:
Each logical zone has a user-defined name assigned to it (Alan Beryl, Finance Department, Sales Department). This name is associated with a zone configuration record that contains the following manually configured data:
Other configuration elements within the device, such as IPSec tunnel, PPTP server, L2TP server, GRE interface or users have a configuration element called “security zone” that allows them to be associated with a ordered list of security zones.
The packet has to match one of the primary matching requirements and then all of the secondary matching requirements associated with the zone configuration record. A packet that does not match any zone is discarded.
Primary matching requirements:
Any zone can be configured to match all packets with the primary requirements.
Secondary matching requirements:
Fragmented support. Default: allow fragments. If fragmented support is disabled, packets that are IP fragments are not associated with the zone.
Referring to
The IPSec tunnel is configured to terminate in VPN logical security zone. The LAN security zone is associated with physical Ethernet port connected to LAN.
The WAN security zone is associated with physical Ethernet port connected to Internet access device.
“This Device” will be defined as a logical security zone associated with packet originating or destined to the firewall device itself.
We will now refer to
Step 101 Start packet processing
The packet is examined and classified by its protocol, its source and destination IP addresses and application. The packet classification record is filled in from this data and compared against a list of session records to determine whether there exists an (acceptable) session corresponding to this packet. The first packet for a session will not find a session entry. A session entry is deleted if the firewall module can determine that the packet corresponds to the end of a session or if the session times out.
A network traffic controller in accordance with a preferred embodiment of the invention will now be described by reference to
User/LAN devices 154 A-154H are connected via connected via network switching fabric 156 to relevant ports 157-159 of the controller 150. Policy rules 165 control the interconnection of devices 154A-H within VLAN1. The ports 157-159 connect via switching fabric to an Ethernet driver 161 which connects the various VLAN to the relevant Ethernet ports 162-164 of the firewall module 151. Policy rules 166 control the layer 2 interconnection of the Ethernet ports 162 and 163 and policy rules 167 control the interconnection of virtual interfaces 152 and 153 and hence control the interconnection in the IP layer of Ethernet port—164 with Ethernet ports 162 and 163.
A security zone can be effectively the same as a VLAN, i.e. a segment of the network that is isolated from other network segments. The network traffic controller always uses VLANs internally for security zones but, like switches, the external Ethernet ports can use untagged VLANs.
Any of the Ethernet ports can be associated with a security zone. If VLAN tagging is enabled and an Ethernet port is associated with a security zone, then that port can be tagged, i.e. the packets to and from the tagged port will contain the VLAN ID associated with the security zone. Otherwise the packets are untagged. In this case, the port can be associated with only one security zone.
If an untagged port is currently associated with a security zone and is configured through the GUI to be associated with another security zone, it will automatically be disassociated from the first security zone. (As with most switches, untagged packets to and from a single Ethernet port can only be associated with a single VLAN (i.e. security zone).
Relationship to IP Subnets
Unlike traditional devices, such as routers, the network traffic controller's IP configuration is not directly associated with a physical port.
The network traffic controller will connect to a single external IP subnet and, optionally, multiple internal IP subnets. Security zones can exist within each IP subnet (internal or external). Firewall policy rules are applied between security zones. Physical Ethernet ports can be associated with any number of security zones when using external VLAN tagging but otherwise must be associated with a single security zone. Packets received on a port with a VLAN tag that is not associated with any of the security zones that contain that port is dropped.
Each IP subnet directly connected to the network traffic controller (internal, external and GRE) will have a Virtual Interface containing its configuration, i.e. IP address, mask, routing protocols enabled, etc.
Security zones that share the same Virtual Interface (VLAN 1 and VLAN 2 in
A Virtual Interface provides an IP interface for the Firewall to allow it to connect to one of the external IP subnets. All IP interfaces are “virtual”; they are associated with physical IP interfaces by the configuration of security zones and physical switch ports.
Physical Ethernet ports are associated with Security zones. Security zones are associated with Virtual Interfaces. A Virtual Interface that has no security zone associated with it is effectively inactive. A security zone must be associated with either the external or exactly one of the internal security zones in order to be effective. Only disassociated security zones can be associated with the external or internal Virtual Interfaces.
There are 3 types of Virtual Interfaces:
An external Virtual Interface is able to be statically configured with or receive its IP configuration from a remote device.
An internal Virtual Interface is able to provide IP configuration via DHCP.
It will be noted from
Ethernet port 4 (not shown) is configured into security zone “WAN” (VLAN ID 3). This fixed zone is associated with its default fixed external Virtual Interface 1. As this is using a separate IP configuration to the other security zones, IP routing with firewall policy occurs between IP interfaces “WAN” and “LAN”. Thus the network traffic controller has very flexible security zones. IP traffic within a security zone is switched at wire speed by the switch subsystem. Traffic that crosses a security zone is firewalled and shaped according to the policy defined between the relevant zones.
The network traffic controller offers flexible physical Ethernet interface configurations, in that they can be associated with an existing security zone or a new security zone associated with either an internal or the external Virtual Interface. Flexible ports are disabled (in switch configuration) in manufacturing.
A flexible port can be configured as a new security zone, or join an existing security zone. If joining an existing security zone, the port becomes switched with the other ports in that same zone by the switch subsystem. If a new security zone, the port becomes firewalled/routed according to the policy rules configured between zones.
The network traffic controller uses two types of security zone internally.
Internal security zones have the following functionality. (External security zones do not support these features):
External security zones have the following functionality. (Internal security zones do not support these features):
When NAT is configured on an internal Virtual Interface, all security zones within the Virtual Interface use NAT. NAT is applied between these internal security zones and any external security zones. NAT is never applied between internal security zones—traffic is always routed (or bridged if the security zones belong to the same Virtual Interface).
A central component of the network traffic controller is controlling the flow of traffic between the physical Ethernet ports on the network traffic controller. Ethernet ports within the same security zone are in the same VLAN and are switched at wire-speed. The traffic between Ethernet ports that are within separate security zones is “policed” by the network traffic controller. The network traffic controller can use VLAN tagging so that traffic on the same physical Ethernet port but using different VLAN tags, is also policed.
The network traffic controller polices packet traffic between the security zones according to a manually configured set of policy rules.
After the initial packet in a session matches a policy rule and creates a firewall session, subsequent packets that match the session will not be rescanned against the policy rules. For applications that create secondary sessions, the Firewall secondary sessions are created when parsing the control channel session.
Policy rules will consist of the following classification components:
As part of policy only, the source or destination security zone can be configured as “This Device”. The “This Device” security zone is for any traffic that is destined for or sent from one of the network traffic controller's Virtual Interface IP addresses. This can be used to control traffic to or from the network traffic controller itself, e.g. to limit or block HTTP management, SNMP management, ping or any other service supported by the network traffic controller.
Note that if “ANY” is selected for the source or destination security zone in a policy rule, this includes the “This Device” security zone.
Policy rules will consist of the following policy components
Policy rules will affect all packet flow through the network traffic controller. Policy rules can be used to restrict VPN tunnelled traffic or provide bandwidth management over VPNs for specific applications by associating the VPN tunnel with one zone, e.g. VPN and applying a policy rule between this zone and, say, the LAN zone.
We have thus described an arrangement in which:—
1) Network policies are specified using logical security zones that are independent of type of network entities being policed—ports, VLANs, tunnels.
2) A single network policy rule can apply to multiple types of network entity. A logical security zone can include a combination of one or more of each type of network entity.
3) Migration from one type of network infrastructure to another (e.g. IPSec tunnelling to GRE tunneling) does not require changes to network policy.
4) New types of network entities (e.g. even new tunnelling protocols) can be introduced without changing policy model.
5) Network policy can apply to each layer within a layered tunnel model. This can be supported by a single device.
6) Any type of action supported by network policy, such as allow, deny, traffic shaping, filtering, logging or redirecting is configured the same way independent of network entity that it is being applied to.
The invention is not restricted to the details of the foregoing examples.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0420428.5 | Sep 2004 | GB | national |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11031776 | Jan 2005 | US |
| Child | 12645548 | US |
