Internet security system

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of prior U.S. provisional application No. 60/280,684, filed Mar. 30, 2001.

BACKGROUND

0002The invention relates to an Internet security system. The growth of the Internet and high-traffic web sites that require high performance and high bandwidth networks have resulted in an increased number of so-called service providers, including Internet data centers, application service and security service providers. A service provider, including an Internet data center, provides network resources, one or more dedicated servers and, in some cases, physical space, to host services for a number of customers, usually for a fee. Conventionally, service providers must install and configure one or more dedicated servers to support each customer and will likely require complex networks to manage separate services for the service provider's customer base. In this environment, the customer typically has some administrative control of the servers and control of the content residing on the servers. An Internet data center typically provides the network, network access, hardware, software and infrastructure needed to power the service, including web site, managed security, and so on.

0003An exemplary view of the organization of a conventional Internet data center is shown in <figref idref="DRAWINGS">FIG. 1</figref>. In the present example, the Internet data center (<b>100</b>) has a number of customers A, B, C, D. The Internet data center (<b>100</b>) shown in <figref idref="DRAWINGS">FIG. 1</figref> is set up for four customers only, while in reality a data center may host hundreds or potentially thousands of users. Each customer has one or more dedicated servers (<b>105</b>), a dedicated firewall (<b>110</b>) and one or more switches (<b>115</b>) that are all connected and form a subnet (<b>120</b>) for that particular customer. The subnets (<b>120</b>) are coupled together in the core switch fabric (<b>125</b>), which in turn forms an interface to the Internet.

0004The conventional model for organizing an Internet data center requires that a separate firewall device be deployed every time a new customer joins the Internet data center, which may require network re-configuration, and be a labor intensive and costly task. In this environment, the staff at the Internet data center must separately configure, upgrade, manage and support each firewall device separately. The conventional way for organizing Internet data centers also requires a heavy need for physical rack space to accommodate the physical installation of separate firewall and other networking devices upon which the provider's services are hosted. As a result of the large amount of separate equipment, the wiring and related switching and routing infrastructure becomes complex. If a firewall fails, it will be costly to repair or replace and the down time the client experiences before his or her firewall has been repaired or replaced may be considerable. The down time can be reduced if redundant boxes are provided, but this solution leads in turn to increased cost, space, maintenance and wiring problems, and is therefore not a desirable solution.

SUMMARY

0005In general, in one aspect, this invention provides methods and apparatus, including computer program products, implementing and using techniques for processing data packets transferred over a network. The data processing system includes a firewall engine that can receive a set of firewall policies and apply the firewall policies to a data packet, an authentication engine that can receive a set of authentication policies and authenticate a data packet in accordance with the authentication policies, one or more virtual private networks that each have an associated destination address and policies and a controller that can detect an incoming data packet, examine the incoming data packet for a virtual private network destination address and identify the policies associated with the virtual private network destination. If the policies include firewall policies, then the controller can call the firewall engine and apply the set of firewall policies corresponding to the virtual private network destination to the data packet. If the policies include authentication policies, then the controller can call the authentication engine and apply the set of authentication policies corresponding to the virtual private network destination to the data packet. The controller can also route the data packet to the virtual private network containing the data packet's destination address.

0006Advantageous implementations can include one or more of the following features. The controller can route the data packet by reading a set of entries in a private routing table and outputting the data packet to its virtual private network destination address using a routing protocol associated with the packet's virtual private network destination address.

0007In general, in one aspect, this invention provides methods and apparatus, including computer program products, implementing and using techniques for processing a data packet in a packet forwarding device. A data packet is received and a virtual local area network destination is determined for the received data packet, including identifying a set of rules that are associated with the virtual local area network destination. The set of rules is applied to the data packet and if a virtual local area network destination has been determined for the received data packet, the data packet is output to its virtual local area network destination, using the result from the application of the rules. If a virtual local area network destination has not been determined for the received data packet, the data packet is dropped.

0008Advantageous implementations can include one or more of the following features. A traffic policy can be applied to the received data packet, the traffic policy being associated with the packet forwarding device and applied to all data packets processed by the packet forwarding device. Determining a virtual local area network destination can include extracting layer information from the data packet and using the extracted layer information to determine a virtual local area network destination for the data packet. The layer information can include layer <b>2</b> information, layer <b>3</b> information, layer <b>4</b> information and layer <b>7</b> information. Applying the rules to the data packet can include shaping the data packet based on the virtual local area network destination and discarding the data packet if no virtual local area network destination is determined. Shaping the data packet can include attaching a digital address tag to the data packet, the digital address tag identifying a virtual local area network destination. The digital address tag can be read and the data packet can be output using the digital address tag content.

0009Applying the rules to the data packet can include applying a set of rules selected from network address translation, mobile internet protocol, virtual internet protocol, user authentication and URL blocking. Applying the rules to the data packet can include applying a set of policies selected from incoming policies and outgoing policies for a virtual local area network destination. Entries from one or more of a global address book, a private address book, and a global service book can be received and applying the rules to the data packet can include using the retrieved entries.

0010Available resources for outputting the data packet to the virtual private network destination can be determined, wherein the resources are definable by a user. Outputting the data packet can include outputting the data packet to a determined virtual private network destination in accordance with the determined available resources. Applying the rules to the data packet can include applying a set of virtual tunneling rules for a virtual local area network destination, where the tunneling rules are selected from PPTP, L2TP and IPSec tunneling protocols. Outputting the data packet can include reading a set of entries in a private routing table and if a virtual local area network destination has been determined for the received data packet, outputting the data packet to its virtual local area network destination using a routing protocol for the packet virtual local area network destination. A set of rules configured by a user can be received.

0011In general, in one aspect, this invention provides methods and apparatus, including computer program products, implementing and using techniques for screening data packets transferred over a network. A connection to one or more virtual local area networks is established. A set of firewall configuration settings are associated with each of the one or more virtual local area networks. An incoming data packet is received. The incoming data packet is screened in accordance with a set of firewall configuration settings and the screened data packet is output to a particular virtual local area network among the one or more virtual local area networks, based on the result of the screening.

0012In general, in one aspect, this invention provides methods and apparatus, including computer program products, implementing and using techniques for transferring packets of data. One or more packet processing engines can receive an incoming packet of data, apply a global traffic policy to the incoming packet, classify the incoming packet including determining a virtual local area network destination, shape the incoming packet based on the virtual local area network destination and output the shaped packet.

0013Advantageous implementations can include one or more of the following features. One or more switches can be connected to the packet processing engine by a trunk cable to receive the shaped packet from the packet processing engine through the trunk cable, determine a destination device to which the shaped packet is to be routed and switch the shaped packet to a communication link that is connected to the destination device. The trunk cable can be a VLAN cable. A first packet processing engine of the one or more packet processing engines can be connected to a first switch of the one or more switches, and cross connected to at least a second switch of the one or more switches and a second packet processing engine of the one or more packet processing engines can be connected to the second switch of the one or more switches and cross connected to at least the first switch of the one or more switches.

0014Each of the first and second switches can connect to one or more communication links, each communication link representing a virtual local area network destination. A trunk cable can connect a switch and a packet processing engine. One or more virtual local area networks (VLANs) can be connected to the one or more switches via a communication link dedicated for the virtual local area network. Outputting the packet can include outputting the shaped packet to its virtual local area network destination through a destination port on the packet processing engine, the destination port connecting the packet processing engine via a communication link to a destination device.

0015One or more virtual local area networks (VLANs) can be connected to a destination port on the packet processing engine via a communication link dedicated for the virtual local area network. Each packet processing engine can perform one or more functions that are configurable for each virtual local area network.

0016In general, in one aspect, this invention provides methods and apparatus, including computer program products, implementing and using techniques for providing a security system including security system resources including firewall services and a controller that can partition the security system resources into a plurality of separate security domains. Each security domain can be configurable to enforce one or more policies relating to a specific subsystem, and to allocate security system resources to the one or more security domains.

0017Advantageous implementations can include one or more of the following features. The security system can allocate security system resources to a specific subsystem. The specific subsystem can be a computer network. The specific subsystem can be a device connected to a computer network. Each security domain can include a user interface for viewing and modifying a set of policies relating to a specific subsystem. The security system resources can include authentication services. The security system resources can include virtual private network (VPN) services. The security system resources can include traffic management services. The security system resources can include encryption services. The security system resources can include one or more of administrative tools, logging, counting, alarming and notification facilities, and resources for setting up additional subsystems.

0018A management device can provide a service domain, the service domain being configurable to enforce one or more policies for all security domains. The management device can include a user interface for viewing, adding and modifying any set of policies associated with any specific subsystem and the set of policies associated with the service domain. The service domain can include a global address book. Each set of security domain policies can include one or more policies for incoming data packets, policies for outgoing packets, policies for virtual tunneling, authentication policies, traffic regulating policies and firewall policies. The policies for virtual tunneling can be selected from the group consisting of PPTP, L2TP and IPSec tunneling protocols. One or more of the security domains can include a unique address book.

0019The invention can be implemented to realize one or more of the following advantages. A single security device can be used to manage security for multiple customers. Each customer has their own unique security domain with an address book and policies for management of content. Each domain is separately administrated. One customer's policies do not interfere with the other customers' policies. Additionally, attacks on one customer's domain will not have any influence on the functionality of other domains. To each customer, the firewall and any virtual private networks (VPNs) appear to be hosted on a discrete device, just like the conventional systems. For an Internet data center that employs the Internet security system in accordance with the invention, a number of benefits may result. Instead of upgrading and managing one device for each customer, a single device can be upgraded and managed for several customers. Less rack space will be required, since fewer devices are necessary, and as a consequence, the wiring scheme will be less complicated. The cost of deployment will be lower, the network complexity and requirements will be reduced, and higher performance throughput will be possible.

0020The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings, and the claims.

DESCRIPTION OF DRAWINGS

0021<figref idref="DRAWINGS">FIG. 1</figref> is a schematic view of a prior art security system configuration for an Internet data center.

0022<figref idref="DRAWINGS">FIG. 2</figref> is a schematic view of an Internet security system in accordance with the invention.

0023<figref idref="DRAWINGS">FIG. 3</figref> is a schematic view of an Internet security system in accordance with an alternative implementation of the invention.

0024<figref idref="DRAWINGS">FIG. 4</figref> is a schematic view of an Internet security system in accordance with another alternative implementation of the invention.

0025<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart showing a data packet processing method in accordance with the invention.

0026<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart detailing one implementation of the packet classification step in <figref idref="DRAWINGS">FIG. 5</figref>.

0027<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart detailing one implementation of the packet classification step in <figref idref="DRAWINGS">FIG. 5</figref>.

0028<figref idref="DRAWINGS">FIG. 8</figref> is a flowchart detailing a alternative implementation of the packet classification step in <figref idref="DRAWINGS">FIG. 5</figref>.

0029<figref idref="DRAWINGS">FIG. 9</figref> is a schematic block diagram showing a more detailed view of the security device in <figref idref="DRAWINGS">FIG. 3</figref>.

0030Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

0031An Internet security system in accordance with the invention provides a multi-customer, multi-domain architecture that allows service providers, such as Internet data centers, application infrastructure providers and metropolitan area network providers to manage the security needs of multiple customers through one centralized system. The inventive Internet security system also allows service provider and end user customers to create and manage separate security domains, each domain acting as a stand alone system and having its own set of policies. The inventive Internet security system accomplishes this through unique architecture and software features that can be referred to as Virtual Systems. The Internet security system will be described by way of example. Three different exemplary architectures will be described with reference to <figref idref="DRAWINGS">FIGS. 2–4</figref>. After the architectural system description of each implementation, the data flow through the system will be described. Finally, the user interface and a number of customizable functions of the Internet security system will be presented.

0032Internet Security System Using Virtual Local Area Networks

0033As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the Internet security system (<b>200</b>) in accordance with one implementation of the invention includes a first 100/1000 router switch (<b>205</b>) that connects a firewall device (<b>210</b>) to the Internet (<b>215</b>). The firewall device (<b>210</b>) acts as a common firewall for all the customers, and can be separately configured to fit each customer's policies and security needs. How the separate configurations are done will be explained in further detail below. On the secure side of the firewall device (<b>210</b>) is a Virtual Local Area Network (VLAN) trunk (<b>220</b>) that carries all packets to a second 100/1000 switch (<b>225</b>). A VLAN is a Layer <b>2</b> multiplexing technique that allows several streams of data to share the same physical medium, such as a trunk cable, while enjoying total segregation. The second switch (<b>225</b>) directs the packets on private links to the different customers' servers (<b>230</b>) through a 10/100 switch (<b>235</b>) for each customer.

0034An incoming data packet from the Internet (<b>215</b>) first passes the router switch (<b>205</b>) and enters the firewall device (<b>210</b>). The firewall device (<b>210</b>) determines what VLAN the packet is intended for and attaches a VLAN tag to the packet. In one implementation, the tag that is used is a 802.1Q tag. The 802.1Q VLAN tag requires 12 bits in the Ethernet packet header to hold the tag, and is defined in the 802.3ac Ethernet frame format standard ratified in 1998. The 802.3ac Ethernet frame format standard is supported by most backbone switches fabricated since the ratification of the standard. There are two ways to attach a tag to a data packet; implicit tagging and explicit tagging. The implicit tagging method assigns a tag to untagged data packets, typically based on which port the data packet came from. The implicit tagging method allows traffic coming from devices not supporting VLAN tagging to be implicitly mapped into different VLANs. The explicit tagging method requires that each data packet be tagged with the VLAN to which the data packet belongs. The explicit tagging method allows traffic coming from VLAN-aware devices to explicitly signal VLAN membership.

0035The packet then continues on VLAN trunk (<b>220</b>) to the VLAN switch (<b>225</b>), where the tag attached to the packet by the firewall device (<b>210</b>) is read. Based on the VLAN tag, the packet is routed by the VLAN switch (<b>225</b>) to the appropriate switch (<b>235</b>) and server (<b>230</b>). The operation of the firewall device (<b>210</b>) will be described in more detail below.

0036Internet Security System Using Port-Based Virtual Local Area Networks

0037Another implementation of the invention is shown in <figref idref="DRAWINGS">FIG. 3</figref>, which shows essentially the same architecture as shown for the Internet security system in <figref idref="DRAWINGS">FIG. 2</figref>. The difference is that the firewall device (<b>210</b>) has been replaced with a firewall device (<b>305</b>) with port-based VLAN. From each port in the firewall with the port based VLAN, there is a private link (<b>310</b>) to each customer, switch (<b>315</b>) and server (<b>320</b>). The system (<b>300</b>) does not include the VLAN trunk or the second 100/1000 switch of the Internet security system implementation shown in <figref idref="DRAWINGS">FIG. 2</figref>.

0038An incoming data packet from the Internet (<b>325</b>) first passes the router switch (<b>330</b>) and enters the firewall device (<b>305</b>). The firewall device (<b>305</b>) determines what system the packet is intended for. Instead of attaching a VLAN tag to the packet, the firewall device directs the packet to the proper dedicated port for the VLAN. The packet then continues on the selected private link (<b>310</b>) to the switch (<b>315</b>) and server (<b>320</b>) for the selected VLAN.

0039<figref idref="DRAWINGS">FIG. 9</figref> shows a more detailed view of the Internet security system of <figref idref="DRAWINGS">FIG. 3</figref>, and in particular of the firewall device (<b>305</b>). The firewall device (<b>305</b>) includes functionality not conventionally included in a firewall and can therefore be referred to more generally as a security system or a data processing system. The security system has a number of engines, such as a firewall engine (<b>905</b>), an authentication engine (<b>910</b>), and optionally other engines. A user interface (<b>985</b>) is also provided in the security system, which allows a user to set different policies for the different engines. The different engines communicate with each other through a bus (<b>920</b>). A user can set firewall policies for the firewall, such as incoming policies and outgoing policies for a virtual local area network destination, and authentication policies for the authentication engine, such as network address translation, mobile Internet protocol, virtual Internet protocol, user authentication and URL blocking.

0040When a packet comes in, a controller (<b>915</b>) detects the packet. The controller is connected to the bus (<b>920</b>) and can communicate with the engines. Also connected to the bus (<b>920</b>) is a set of virtual private networks (<b>925</b>–<b>940</b>), that each are connected to a network, optionally through one or more switches (<b>315</b>). The exemplary networks shown in <figref idref="DRAWINGS">FIG. 9</figref> include two DMZs (Demilitarized Zones) (<b>965</b>,<b>970</b>), an extranet (<b>975</b>) and a general population net (<b>980</b>). Each of the virtual private networks (VPNs), has an associated destination address and policies. After the packet has been detected by the controller (<b>915</b>), the controller (<b>915</b>) examines the data packet for a virtual private network destination address and identifies the policies that are associated with the virtual private network destination. If the policies include firewall policies, the controller (<b>915</b>) calls the firewall engine (<b>905</b>), which applies the set of firewall policies corresponding to the virtual private network destination to the data packet. If the policies include authentication policies, the controller (<b>915</b>) calls the authentication engine (<b>910</b>), which applies the set of authentication policies corresponding to the virtual private network destination to the data packet. After the respective engine has applied the policies, the data packet is routed to the virtual private network corresponding to the data packet's destination address. How the incoming data packet is examined will be described in greater detail below.

0041The security system as a whole thus has a finite amount of security system resources, including firewall and authentication services. The controller partitions the security system resources into a number of separate security domains, each security domain being related to a private or public network. Each security domain is configurable to enforce one or more policies relating to a specific subsystem or network. The controller allocates security system resources to the one or more security domains based on the needs of the respective security domain, by calling the different engines, as described above. Instead of the static resource allocation in conventional Internet security systems with one security device or firewall per client, as was described in the background section above, the inventive Internet security system provides dynamic resource allocation on a as needed basis for the different virtual private networks and associated systems.

0042The security system resources can include a wide range of resources, such as authentication services, virtual private network (VPN) services, include traffic management services, encryption services, administrative tools, logging, counting, alarming and notification facilities, and resources for setting up additional subsystems.

0043Internet Security System Using Virtual Local Area Networks with High Availability

0044Yet another implementation of the invention is shown in <figref idref="DRAWINGS">FIG. 4</figref>, which shows an Internet security system architecture (<b>400</b>) similar to that shown in <figref idref="DRAWINGS">FIG. 2</figref>. However, in order to provide the ability to accommodate more traffic and to provide higher availability in the event of equipment failure, the system provides dual firewalls (<b>405</b>, <b>410</b>) and dual second switches (<b>415</b>, <b>420</b>). The first switches have been replaced with switch/routers (<b>425</b>,<b>430</b>) that can direct incoming traffic to either firewall (<b>405</b>, <b>410</b>). Each firewall is connected to both second switches (<b>415</b>, <b>420</b>) through VLAN trunks (<b>435</b>), and each of the second switches is connected to all the customer switches (<b>440</b>) by private links (<b>445</b>). The cross connection scheme ensures that an alternate route for data packages will be available, even in the event of component failure, and a high availability is thereby ensured.

0045An incoming data packet from the Internet arrives at one of the router switches (<b>425</b>, <b>430</b>). The router switch decides what firewall device (<b>405</b>, <b>410</b>) to send the packet to, based on which firewall device currently has most available capacity and sends the packet to that firewall device. Just like the above-described implementation shown in <figref idref="DRAWINGS">FIG. 2</figref>, the firewall device ( <b>405</b>, <b>410</b>) determines what VLAN the packet is intended for, and attaches a VLAN tag to the packet. The packet then continues on VLAN trunk (<b>435</b>) to the VLAN switch (<b>415</b>,<b>420</b>) with the most available capacity, where the tag attached to the packet by the firewall device (<b>405</b>, <b>410</b>) is read. Based on the VLAN tag, the packet is routed by the VLAN switch (<b>415</b>,<b>420</b>) through a private link (<b>445</b>) to the appropriate switch (<b>440</b>) and server (<b>450</b>).

0046Packet Classification and Context Partition

0047The following example describes a process for classifying and sending out an incoming packet to the appropriate virtual system using the firewall device in the Internet security system in accordance with the invention. As shown in <figref idref="DRAWINGS">FIG. 5</figref>, a process (<b>500</b>) for classifying and sending out an incoming data packet begins with receiving a data packet (<b>505</b>). In the present example, the data packet is assumed to come from a trusted host. Data packets that are received from an untrusted host will be treated somewhat differently, which will be described below.

0048Once the data packet has been received, the layer <b>2</b> (L<b>2</b>) information and the layer <b>3</b> (L<b>3</b>) information is extracted from the packet (<b>510</b>). The L<b>2</b> information includes: Interface Number and VLAN ID. The L<b>3</b> information includes IP head or information.

0049After the L<b>2</b> and L<b>3</b> information has been extracted, one or more global traffic policies are applied to the packet (<b>515</b>). The global traffic policies apply to all virtual system domains in the Internet security system.

0050When the global traffic policies have been applied, the packet goes through a classification (<b>520</b>) to find a Virtual System Context. The virtual system context is an object containing all the configuration parameters for the virtual system to which the packet is destined. The packet classification is based a combination of the interface, VLAN ID and/or L<b>3</b>/L<b>4</b> (that is, TCP/UDP port) information. In a simple configuration, Interface and VLAN ID will be sufficient, while in a more complicated configuration, all the information listed above is necessary to locate the right context. The packet classification step is essential for the method and will be described in further detail below after the overall data packet processing procedure has been described.

0051The procedure then checks if a virtual system context has been found (<b>525</b>). If no virtual system context can be found, the packet is dropped and the event is logged (<b>530</b>). If a virtual system context has been found, the packet will be subjected to firewall/VPN/traffic shaping processing (<b>535</b>), in the same way as the packet would be processed on a stand-alone device. After the firewall/VPN/traffic shaping processing the procedure transforms the packet into an egress packet, and the L<b>2</b> information is encapsulated (<b>540</b>) before the packet is transmitted out through a designated interface port to the proper Virtual private network, which completes the procedure.

0052If the incoming packet comes from an untrusted interface, the processing is somewhat different than when the packet originates at a trusted interface. The different processing is necessary because an untrusted interface may be shared among several virtual systems. Therefore, the packet classification step (<b>520</b>) will, optionally, use more information, such as tunnel identifications for protocols such as IPSEC, L2TP. When a tunnel has been identified, the virtual system context can be identified, and the packet can pass to the Firewall/VPN/Traffic shaping step (<b>535</b>).

0053For non-tunnel traffic, a policy-based and session-based look-up table may be used to identify a virtual system context for the traffic from an untrusted interface. In the packet classification step (<b>520</b>), the packet will be subject to a global policy in order to identify if there is a session anywhere in the whole security system that matches with the packet. If such a session exists, the context point in the session record informs the security system about which virtual system context is the correct one. If there is no session match, but there is a policy that matches the packet, then that policy will point to the proper virtual system context for continued processing.

0054The classification step (<b>520</b>) described above determines to which virtual system the incoming data packet is destined. The classification step (<b>520</b>) will now be described in more detail with reference to <figref idref="DRAWINGS">FIGS. 6–8</figref> that show in greater what happens to the data packet during the classification. Conceptually, the Internet security system in accordance with the invention can be viewed as processes in an operating system, the primary difference being that processes in an operating system are event driven, while the Internet security system is packet driven. When the Internet security system receives an incoming data packet, the system needs to classify the packet based on information contained in the packet and on the policies that have been configured for the system. When the packet has been classified, the virtual system context to which the packet belongs is found, and the packet is passed to the associated virtual system context for further processing. From the point of view of the virtual system, the packet appears to have originated in one of the virtual interfaces configured for the virtual system.

0055The classification of the incoming packet is made based on information from layer <b>2</b> (L<b>2</b>), layer <b>3</b> (L<b>3</b>), layer <b>4</b> (L<b>4</b>) and layer <b>7</b> (L<b>7</b>) information. The classification may be made based on one or more layers. For example, in a simple configuration, a virtual system using VLAN to separate different secure domains, the VLAN ID in the VLAN Ethernet packet is sufficient to classify the packet and identify the destination virtual system context. This is referred to as simple classification. An exemplary process for simple classification is shown in <figref idref="DRAWINGS">FIG. 6</figref>, where the L<b>2</b> information is extracted (<b>605</b>), the virtual interface table is searched with the VLAN ID and the interface number (<b>610</b>). Based on the VLAN ID and the interface number, the process can determine whether a virtual system context has been found (<b>615</b>). If no virtual system context can be found, then the simple classification is not sufficient (<b>620</b>), and if a virtual system context can be found, then the simple classification is sufficient (<b>625</b>).

0056In an Internet security system with shared outside identity, a session database is used along with L<b>2</b>, L<b>3</b> and L<b>4</b> information to identify the correct virtual system. This is referred to as multi-layer classification. A process for multi-layer classification is shown in <figref idref="DRAWINGS">FIG. 7</figref>, where the L<b>2</b> information (<b>705</b>), the L<b>3</b> information (<b>710</b>) and the L<b>4</b> information is extracted (<b>715</b>), before the session database is searched (<b>720</b>). Based on the L<b>2</b>, L<b>3</b> and L<b>4</b> information and the information in the session database, the process can determine whether a virtual system context has been found (<b>725</b>). If no virtual system context can be found, then the multi-layer classification is not sufficient (<b>730</b>), and if a virtual system context can be found, then the multi-layer classification is sufficient (<b>735</b>).

0057When complicated applications with dynamic port session (such as, FTP, RPC, H.323, and so on) are involved, a dynamic session database, along with L<b>2</b>, L<b>3</b>, L<b>4</b>, and L<b>7</b> (application layer) information are used to identify the virtual system context. This is referred to as L<b>7</b> classification. A process for L<b>7</b> classification is shown in <figref idref="DRAWINGS">FIG. 8</figref>, where the L<b>2</b> (<b>805</b>), the L<b>3</b> (<b>810</b>), the L<b>4</b> (<b>815</b>) and the L<b>7</b> information is extracted (<b>820</b>) before the dynamic session database is searched (<b>825</b>). Based on the L<b>2</b>, L<b>3</b>, L<b>4</b>, and L<b>7</b> information and the dynamic session database, the process can determine whether a virtual system context has been found (<b>830</b>). If no virtual system context can be found, then the simple classification is not sufficient (<b>835</b>), and if a virtual system context can be found, then the simple classification is sufficient (<b>840</b>). Each of the simple, multi-layer or L<b>7</b> classification can be performed by itself, or the processes can be performed in series, going from the simple classification, through the multi-layer classification to the L<b>7</b> classification until the packet has been classified and a virtual system context has been identified.

0058The virtual systems are created through configuration of the Internet security system in real time or at start up with a saved configuration script. A system administrator creates virtual system context under a root privilege, and assigns certain attributes to the context. The system resources are now partitioned to support the new virtual system. A virtual system user can then log in to the system and will only see his or her virtual system, as if the user owned the whole system. A virtual system owner then can add, change and remove different attributes on the context. Once submitted, all attributes will be saved as configuration data for the Internet security system and be used to partition resources, change the global classification policy, and so on. How the Internet security system and individual virtual systems can be configured will be discussed in further detail below.

0059Configuring an Internet Security System

0060The description will now continue with an example showing how to configure an Internet security system in accordance with the invention, and showing three different examples of the user interfaces: one for a root level configuration, one where a root user creates a virtual system and adds configuration data, and one where a virtual system user logs in to a virtual system and changes configuration data.

0061First, a root user (that is, a system administrator for the whole Internet security system) with the user name “Netscreen” logs in to the system by entering the username and a password: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0062">login: Netscreen</li><li id="ul0002-0002" num="0063">password:</li><li id="ul0002-0003" num="0064">ns1000-></li></ul></li></ul>

0065The root user is now logged on and can access the root level interface configuration to view the different user interfaces that are present on the system. The command ‘get interface,’ for example, yields the following five interfaces, shown in Table 1 below.

0066<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>User interfaces present on the Internet Security System</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="49pt" align="left" /><colspec colname="5" colwidth="63pt" align="left" /><colspec colname="6" colwidth="49pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Stat</entry><entry>IP Address</entry><entry>Subnet Mask</entry><entry>MAC/VLAN/VSYS</entry><entry>Manage IP</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry>Trust</entry><entry>Down</entry><entry>10.1.1.250</entry><entry>255.255.255.0</entry><entry>0010.dbf.1000</entry><entry>0.0.0.0</entry></row><row><entry>Trust/1</entry><entry>Down</entry><entry>11.1.1.250</entry><entry>255.255.255.0</entry><entry>Nat/trust.100(100)/</entry><entry>0.0.0.0</entry></row><row><entry /><entry /><entry /><entry /><entry>NULL</entry></row><row><entry>Untrust</entry><entry>Down</entry><entry>192.1.1.250</entry><entry>255.255.255.0</entry><entry>0010.dbf0.1001</entry></row><row><entry>Mgt</entry><entry>Up</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>0010.dbf0.1002</entry><entry>192.168.1.1</entry></row><row><entry>Ha</entry><entry>Down</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>0010.dbf0.1004</entry><entry>192.168.1.1</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0067The root user can view the root level address entry configuration with the command ‘get address’ which yields the trusted, untrusted, and virtual addresses shown in Table 2 below:

0068<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Trusted, Untrusted, and Virtual Addresses</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="70pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Address</entry><entry>Netmask</entry><entry>Flag</entry><entry>Comments</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Trusted Individual Addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="70pt" align="left" /><tbody valign="top"><row><entry>Inside Any</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>02</entry><entry>All trusted addr.</entry></row><row><entry>T11net</entry><entry>11.1.1.0</entry><entry>255.255.255.0</entry><entry>00</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Untrusted Individual addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="70pt" align="left" /><tbody valign="top"><row><entry>Outside Any</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>03</entry><entry>All Untrusted Addr</entry></row><row><entry>Dial-Up VPN</entry><entry>255.255.255.255</entry><entry>255.255.255.255</entry><entry>03</entry><entry>Dial-Up VPN Addr</entry></row><row><entry>u-199net</entry><entry>199.1.1.0</entry><entry>255.255.255.0</entry><entry>01</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Virtual Individual Addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="70pt" align="left" /><tbody valign="top"><row><entry>All Virtual Ips</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>12</entry><entry>All Virtual Addr</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0069The root user can view the Virtual Private Network configuration by typing the command ‘get vpn’ which yields the virtual private network configuration in Table 3 below. Here, there is only one VPN setting for the system.

0070<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>VPN systems for the Internet Security System</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="35pt" align="center" /><colspec colname="4" colwidth="49pt" align="center" /><colspec colname="5" colwidth="49pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><tbody valign="top"><row><entry>Name</entry><entry>Gateway</entry><entry>Local SPI</entry><entry>Remote SPI</entry><entry>Algorithm</entry><entry>Monitor</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry>m-t11-u199</entry><entry>192.2.1.250</entry><entry>00001234</entry><entry>00004321</entry><entry>Esp:3des/null</entry><entry>Off</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry namest="1" nameend="6" align="left" id="FOO-00001">Total manual VPN: 1</entry></row></tbody></tgroup></table></tables>

0071To view the access policy configuration, the root user types the command ‘get policy’ which yields the three policies shown in Table 4 below for the root system.

0072<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Policies for the root system in the Internet Security System</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="28pt" align="center" /><colspec colname="6" colwidth="28pt" align="left" /><colspec colname="7" colwidth="28pt" align="center" /><tbody valign="top"><row><entry>PID</entry><entry>Direction</entry><entry>Source</entry><entry>Destination</entry><entry>Service</entry><entry>Action</entry><entry>STLC</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry>0</entry><entry>Outgoing</entry><entry>T-11net</entry><entry>u-199net</entry><entry>Any</entry><entry>Tunnel</entry><entry>—</entry></row><row><entry>1</entry><entry>Incoming</entry><entry>U-199net</entry><entry>t-11net</entry><entry>Any</entry><entry>Tunnel</entry><entry>—</entry></row><row><entry>2</entry><entry>Inside</entry><entry>Any</entry><entry>Outside</entry><entry>Any</entry><entry>Permit</entry><entry>—</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0073The description will now continue with explaining how the root user can create a new virtual system named “marketing” and configure that system. The root user first adds the virtual system “marketing” to the Internet security system.

0074ns1000->set vsys marketing

0075The root user then adds configuration data to the newly created system “marketing” by first adding two virtual interfaces for the “marketing” system. Note how the prompt has changed to indicate that the root user is working in the “marketing” system.

0076ns1000(marketing)->set interface trust/200 ip 20.1.1.250 255.255.255.0 tag 200

0077ns1000(marketing)->set interface untrust/200 ip 193.1.1.250 255.255.255.0 tag 200

0078The next configuration to update is to add a virtual system private address entry to the “marketing” system.

0079ns1000(marketing)->set address trust t-20net 20.1.1.64 255.255.255.128

0080The root user then adds a MIP attribute to the private virtual interface, as well as two incoming/outgoing policies.

0081ns1000(marketing)->set interface untrust/200 mip 193.1.1.241 host 20.1.1.40

0082ns1000(marketing)->set policy incoming out-any mip(193.1.1.241) http permit

0083ns1000(marketing)->set policy outgoing t-20net out-any any permit auth

0084Next, the root user can verify the interface configuration settings by typing the command ‘get interface’. As shown above, the ‘get interface’ command yields the virtual interfaces for the current system. Since the current system is the “marketing” system, the root user will only see two virtual interfaces crated above, as shown in Table 5 below.

0085<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Virtual interfaces for the “marketing” virtual system</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="49pt" align="center" /><colspec colname="5" colwidth="91pt" align="left" /><colspec colname="6" colwidth="35pt" align="center" /><tbody valign="top"><row><entry>Name</entry><entry>Stat</entry><entry>IP Address</entry><entry>Subnet Mask</entry><entry>MAC/VLAN/VSYS</entry><entry>Manage IP</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="49pt" align="center" /><colspec colname="5" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>Trust/200</entry><entry>Down</entry><entry>20.1.1.250</entry><entry>255.255.255.0</entry><entry>Nat/trust.200(200)/marketing</entry></row><row><entry>Trust/200</entry><entry>Down</entry><entry>193.1.1.250</entry><entry>255.255.255.0</entry><entry>Route/untrust.200(200)/</entry></row><row><entry /><entry /><entry /><entry /><entry>marketing</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0086As described above, the root user can see the virtual system address configuration for the “marketing” system by typing the command ‘get address,’ which yields the address entries shown in Table 6 below.

0087<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Address entries for the “marketing” system</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Address</entry><entry>Netmask</entry><entry>Flag</entry><entry>Comments</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Trusted Individual Addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>Inside Any</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>02</entry><entry>All trusted addresses</entry></row><row><entry>T-20net</entry><entry>20.1.1.64</entry><entry>255.255.255.128</entry><entry>00</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Untrusted Individual addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>Outside Any</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>03</entry><entry>All Untrusted Addresses</entry></row><row><entry>Dial-Up VPN</entry><entry>255.255.255.255</entry><entry>255.255.255.255</entry><entry>03</entry><entry>Dial-Up VPN Addresses</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>Virtual Individual Addresses:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>All Virtual Ips</entry><entry>0.0.0.0</entry><entry>0.0.0.0</entry><entry>12</entry><entry>All Virtual Addresses</entry></row><row><entry>MIP</entry><entry>193.1.1.241</entry><entry>255.255.255.255</entry><entry>10</entry><entry>Untrust/200</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0088The user can now retrieve the policies for the “marketing” system by typing the command ‘get policy’ at the prompt. The get policy command yields the following two policies for the “marketing” system, shown in Table 7 below.

0089<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Policies for the “marketing” system</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="49pt" align="left" /><colspec colname="5" colwidth="28pt" align="left" /><colspec colname="6" colwidth="28pt" align="left" /><colspec colname="7" colwidth="28pt" align="center" /><tbody valign="top"><row><entry>PID</entry><entry>Direction</entry><entry>Source</entry><entry>Destination</entry><entry>Service</entry><entry>Action</entry><entry>STLC</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry>0</entry><entry>Incoming</entry><entry>Outside</entry><entry>MIP</entry><entry>HTTP</entry><entry>Permit</entry><entry>—</entry></row><row><entry /><entry /><entry>Any</entry><entry>(193.1.1.124)</entry></row><row><entry>1</entry><entry>Outgoing</entry><entry>t-20net</entry><entry>Outside Any</entry><entry>Any</entry><entry>Permit-</entry><entry>—</entry></row><row><entry /><entry /><entry /><entry /><entry /><entry>Auth</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0090The configuration file for the “marketing” system virtual system can be obtained by typing ‘get config’ which yields: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0091">Total Config size 1503:</li><li id="ul0004-0002" num="0092">set vsys “marketing”</li><li id="ul0004-0003" num="0093">set vsys-id 1</li><li id="ul0004-0004" num="0094">set auth type 0</li><li id="ul0004-0005" num="0095">set auth timeout 10</li><li id="ul0004-0006" num="0096">set admin name “vsys_marketing”</li><li id="ul0004-0007" num="0097">set admin password nIxrDlr7BzZBcq/LyshENtLt9sLGFn</li><li id="ul0004-0008" num="0098">set interface trust/200 ip 20.1.1.250 255.255.255.0 tag 200</li><li id="ul0004-0009" num="0099">set interface untrust/200 ip 193.1.1.250 255.255.255.0 tag 200</li><li id="ul0004-0010" num="0100">set interface untrust/200 mip 193.1.1.241 host 20.1.1.40 netmask 255.255.255.255</li><li id="ul0004-0011" num="0101">set address trust “t-20net” 20.1.1.64 255.255.255.128</li><li id="ul0004-0012" num="0102">set policy id 0 incoming “Outside Any” “MIP(193.1.1.241)” “HTTP” Permit</li><li id="ul0004-0013" num="0103">set policy id 1 outgoing “t-20net” “Outside Any” “ANY” Permit Auth</li><li id="ul0004-0014" num="0104">exit</li></ul></li></ul>

0105The root user has now created a virtual system, configured the system, and verified that all the settings are correct. He or she then exits the marketing system, saves the new configuration and the prompt returns to the root level.

0106ns1000(marketing)->exit

0107Configuration modified, save? [y]/n y

0108Save System Configuration . . . Done

0109ns1000>

0110The current Internet security system settings can now be viewed by the root user by typing ‘get vsys’, which yields the settings shown in Table 8 below. As can be seen the Internet security system now has a marketing system and a sales system. The marketing system has one sub-interface, while the sales system has a trusted and an untrusted interface.

0111<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Internet security system settings</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="14pt" align="center" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="84pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>ID</entry><entry>Sub-interface</entry><entry>VLAN</entry><entry>IP/Netmask</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>Marketing</entry><entry>1</entry><entry>Trust/200</entry><entry>Trust.200</entry><entry>20.1.1.250/255.255.255.0</entry></row><row><entry>Sales</entry><entry>2</entry><entry>Trust/300</entry><entry>Trust.300</entry><entry>30.1.1.250/255.255.255.0</entry></row><row><entry /><entry /><entry>Untrust/200</entry><entry>Untrust.200</entry><entry>193.1.1.250/255.255.255.0</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0112The description will now continue with showing what a user of a virtual system, a “marketing” system, sees and the operations he or she can perform when he logs in to the system. The user logs in with his username and password: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0113">login: vsys_marketing</li><li id="ul0006-0002" num="0114">password:</li><li id="ul0006-0003" num="0115">ns1000(marketing)-></li></ul></li></ul>

0116To change the policy configuration, the user types ‘get policy’ which yields the two policies shown in Table 7 above. Now, the user can remove the first policy with the command ‘unset policy 1’ and add a new policy to the “marketing” system by typing

0117ns1000(marketing)->set policy outgoing in-any out-any any permit auth

0118The new policy configuration can be shown by retyping the ‘get policy’ command, which yields the policies shown in Table 9 below.

0119<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 9</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Modified policies for the “marketing” system</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="49pt" align="left" /><colspec colname="5" colwidth="28pt" align="left" /><colspec colname="6" colwidth="28pt" align="left" /><colspec colname="7" colwidth="28pt" align="center" /><tbody valign="top"><row><entry>PID</entry><entry>Direction</entry><entry>Source</entry><entry>Destination</entry><entry>Service</entry><entry>Action</entry><entry>STLC</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry>0</entry><entry>Incoming</entry><entry>Outside</entry><entry>MIP</entry><entry>HTTP</entry><entry>Permit</entry><entry>—</entry></row><row><entry /><entry /><entry>Any</entry><entry>(193.1.1.124)</entry></row><row><entry>2</entry><entry>Outgoing</entry><entry>Inside</entry><entry>Outside Any</entry><entry>Any</entry><entry>Permit-</entry><entry>—</entry></row><row><entry /><entry /><entry>Any</entry><entry /><entry /><entry>Auth</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0120The user can then exit the “marketing” system and save the modified policies in the same way as the root user exited: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0121">ns1000(marketing)->exit</li><li id="ul0008-0002" num="0122">Configuration modified, save? [y]/n y</li><li id="ul0008-0003" num="0123">Save System Configuration . . . Done</li></ul></li></ul>

0124The above examples only showed how to change a few policies and components. In the Internet security system in accordance with the invention, the following components can be independently configured in a similar way to the above example:

0125Firewall—The firewall device can be configured for each user to include one or more of the following mechanisms: NAT (Network Address Translation), MIP/VIP (Mapped IP, Virtual IP), User authentication, URL Blocking.

0126Policy—A private policy set can be configured that is applied to traffic for a particular customer. The private policy can include both incoming and outgoing policies. The policies can use entries from a global address book, a defined private address book, and a global service book.

0127Traffic management—Each virtual interface can be given a specific bandwidth.

0128Administration and management—Various functions can be configured for administration purposes, such as administrator login, mail alert, syslog, counters, logs and alarms.

0129Virtual LAN—The Virtual LAN can be defined on virtual interfaces within the Internet security system. Once the virtual LAN has been defined, the received VLAN traffic will be directed to the indicated virtual interface and traffic destined to the indicated virtual interface will be properly tagged with a VLAN ID.

0130VPN—Combined with private policies, the VPN provides secure tunneling for selected traffic going through the Internet security system. The tunneling can be PPTP, L2TP and IPSec.

0131Routing—Each system may define a private routing table and routing protocol.

0132A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.