Abstract:
Methods and systems for processing network content associated with multiple virtual domains are provided. According to one embodiment, a service daemon process is instantiated within a firewall to handle content processing of network traffic of virtual domains by aggregating communication channels associated with the virtual domains and by applying an appropriate content processing policy for the corresponding virtual domain. A connection request is received by the firewall from a virtual domain. A child process is forked by the service daemon process to handle network traffic associated with the virtual domain. A communication channel is established between a kernel of the firewall and the service daemon process to transfer a portion of the network traffic between the service daemon process and the kernel. The child process is configured to perform content processing of the network traffic in accordance with a content processing policy associated with the virtual domain.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 13/558,822, filed Jul. 26, 2012, which is a continuation of U.S. patent application Ser. No. 11/331,031, filed Jan. 13, 2006, now U.S. Pat. No. 8,234,361, both of which are hereby incorporated by reference in their entirety for all purposes. 
     
    
     COPYRIGHT NOTICE 
       [0002]    Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright© 2006-2013, Fortinet, Inc. 
       BACKGROUND 
       [0003]    1. Field 
         [0004]    Embodiments of the present invention generally relate to computer networking. In particular, embodiments of the present invention relate to achieving security and/or scalability in networking systems. 
         [0005]    2. Description of the Related Art 
         [0006]    Security threats have evolved dramatically over the last 10 years, moving from network-level, connection-oriented attacks to application-level, agent-based attacks. Conventional networking devices (firewalls) can deal with network-level packet processing; for example, conventional firewalls can stop packets that do not come from a valid source, and VPN gateways can encrypt packets on the fly, making it safe for them to traverse the Internet. But today&#39;s critical network threats, like malware, which includes spyware, viruses and worms, are embedded in the application-level contents of packet streams. Enormous processing power is needed to detect and stop these application-layer threats by extracting the content from multiple packets, reconstructing the original content, and scanning it for the telltale signs of attacks or for inappropriate content. 
         [0007]    To address these security challenges, modern firewalls must offer application-level content processing in real time—especially for real-time applications (like Web browsing) at today&#39;s (and tomorrow&#39;s) increasing network speeds. 
         [0008]    In a firewall, processing of network traffic is determined by a set of specific rules which collectively form a firewall policy. The firewall policy dictates how the firewall should handle specific applications network traffic such as web, email or telnet. Exemplary rules include filtering of banned words, blocking specific URLs, blocking transmission of specific file types, anti-malware scans, blocking of spam, etc. Each firewall policy generally has an associated firewall configuration profile, which configures the firewall to process the network content. The firewall policy is usually created by the network administrator and is based on the information security policy of the respective organization. 
         [0009]    A firewall is typically implemented as a hardware/software appliance having a number of physical networking interfaces for the incoming and outgoing network traffic. Network traffic enters one of these interfaces and, after filtering and other appropriate processing, is routed to a remote host typically attached to a different physical interface. In some circumstances, firewalls are configured to also have logical interfaces, such as Virtual Local Area Network (VLAN) or Point To Point Protocol (PPP) interfaces. Such logical interfaces are purely software-implemented and do not map directly to a physical interface. For example, in VLAN configuration, PCs, servers and other network devices communicate as if they were on the same physical LAN segment, even though they may not be. The networking entities in VLAN configuration may be scattered across multiple physical networks, but to the firewall they appear as if they were all connected through a single (logical) network interface. 
         [0010]    Large networks having multiple diverse computer systems can be subdivided into two or more disjoint virtual networks, called “virtual domains”. Each such virtual domain has its own routing, network administration, assess privileges as well as network security policies and configurations. Virtual domains can be used, for example, by separate organizations to share the same firewall/routing hardware, the networking interfaces of which can be segregated into disjoint routing domains, which may be administered by different users. Traffic originating from one such virtual domains can only be routed within the same virtual domain. 
         [0011]    Unfortunately, the existing firewall systems are deficient in their ability to handle disjoint routing and configuration domains in a scalable and efficient manner. Therefore, what is needed is a scalable firewall system with an ability to manage virtual networking domains in an efficient manner. 
       SUMMARY 
       [0012]    Methods and systems are described for processing network content associated with multiple virtual domains. According to one embodiment, a service daemon process is instantiated within a firewall. The service daemon process handles content processing of network traffic for multiple virtual domains coupled to the firewall by aggregating communication channels associated with the virtual domains and by applying to the network traffic an appropriate content processing policy corresponding to the virtual domain with which the network traffic is associated. A first connection request is received by the firewall involving a first virtual domain of the virtual domains. A first child process is forked by the service daemon process to handle network traffic associated with the first virtual domain. A first communication channel is established for the first virtual domain between a kernel of the firewall and the service daemon process to transfer at least a portion of the network traffic associated with the first virtual domain between the service daemon process and the kernel. The first child process is configured to perform content processing in accordance with a first content processing policy of the first virtual domain. The first child process performs content processing of the network traffic associated with the first virtual domain based on the first content processing policy. 
         [0013]    Other features of embodiments of the present invention will be apparent from the accompanying drawings and from the detailed description that follows. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: 
           [0015]      FIG. 1  depicts a conceptual block-diagram of a virtual local area network (VLAN) configuration. 
           [0016]      FIG. 2  depicts a conceptual block-diagram of a virtual domain configuration. 
           [0017]      FIG. 3  illustrates a conceptual block-diagram of a computerized system for processing network content in a virtual domain environment in accordance with an embodiment of the present invention. 
           [0018]      FIG. 4  illustrates a conceptual block-diagram of a computerized system for processing network content in a virtual domain environment in accordance with an alternative embodiment of the present invention. 
           [0019]      FIG. 5  illustrates an exemplary computer platform upon which the inventive content processing system may be implemented. 
       
    
    
     DETAILED DESCRIPTION 
       [0020]    Methods and systems are described for processing network content associated with multiple virtual domains. In the following detailed description, reference will be made to the accompanying drawing(s), in which identical functional elements are designated with like numerals. The aforementioned accompanying drawings show by way of illustration, and not by way of limitation, specific embodiments and implementations consistent with principles of the present invention. These implementations are described in sufficient detail to enable those skilled in the art to practice the invention and it is to be understood that other implementations may be utilized and that structural changes and/or substitutions of various elements may be made without departing from the scope and spirit of present invention. The following detailed description is, therefore, not to be construed in a limited sense. Additionally, the various embodiments of the invention as described may be implemented in the form of a software running on a general purpose computer, in the form of a specialized hardware, or combination of software and hardware. 
         [0021]    The inventor recognized that it would have been advantageous to provide a mechanism whereby network content for multiple virtual domains is managed in a scalable and efficient manner. Specifically, an embodiment of the inventive technique can simultaneously process network content associated with multiple virtual domains. 
         [0022]      FIG. 1  shows an exemplary VLAN network configuration  100 . With reference to  FIG. 1 , physical local area networks (LAN)  122 ,  123  and  124  are carried by the physical interfaces of the firewall appliance  101 . The physical LANs  122 - 124  include local network entities  104 - 115  connected to the respective physical network interfaces of the firewall  101 . The local network entities may include PCs, network storage devices, etc. The local network entities  104 - 115  are grouped into three VLANs  116 ,  117  and  118 , which are associated in the firewall  101  with logical interfaces  119 ,  120  and  121 , respectively. The firewall  101  is coupled to the Internet  102  via a different physical interface  125 . Network content transferred between a remote host  103  on the Internet  102  and any of the local entities  104 - 115  is processed by the firewall  101  in accordance with the firewall policy in effect. Such processing may include anti-malware scanning and/or content filtering. 
         [0023]      FIG. 2  illustrates an exemplary network configuration  200 , with multiple virtual domains. Specifically, the local network entities  104 - 111  located on physical networks  122  and  123  are grouped into two VLANs  216  and  217 , as described above. The VLANs  216  and  217  are associated in the firewall  101  with logical interfaces  219  and  220 , respectively. Local network entities  112 - 115  are located on the physical network  124 , which associated with firewall&#39;s physical interface  225 . Logical interfaces  219  and  220  as well as physical interface  225  (and all the associated network entities) are grouped into two disjoint networks or virtual domains  226  and  227 . Network traffic originating within each of these virtual domains can only be routed within the same virtual domain. The network content transmitted between the remote host  103  on the Internet  102  and the entities within the virtual domains  226  and  227  is processed by the firewall  101 . Each of the virtual domains  226  and  227  may have different content processing policies (not shown) in effect for handling network content associated with the respective virtual domain. Virtual domains  226  and  227  have disjoint routing, including the routing to the Internet. Therefore additional routers (or logical interfaces)  228  and  229  are provided to segregate the traffic between each virtual domain and the Internet. In addition, the remote host  103  would normally be allowed to connect to one of the virtual domains  226  and  227 , but not both. 
         [0024]      FIG. 3  illustrates a conceptual block-diagram of a computerized system for processing network content in a virtual domain environment in accordance with an embodiment of the present invention. With reference to  FIG. 3 , the shown embodiment of the inventive firewall system  300  comprises logical interfaces  219  and  220  and physical interface  225 . Logical interface  220  and physical interface  225  together form a virtual domain  227 . Virtual domain  226  is associated with the single logical interface  219 . Local network entities  104 - 115  are grouped into virtual domains  226  and  227  in accordance with grouping of their respective interfaces. 
         [0025]    The network traffic transmitted by the firewall is processed by firewall daemon processes  305  and  306 . Specifically, in the shown embodiment service daemon process  305  performs content filtering for virtual domains  226  and  227 , while service daemon  305  handles anti-malware scanning of the content. Service processes  305  and  306  communicate with interfaces  219 ,  220  and  225  through separate communication channels and specifically sockets  315 - 318 . In an embodiment of the inventive system, each of these sockets has its own receive buffer such that packets from one virtual domain do not overflow the buffer corresponding to another virtual domain. Therefore, overflow of a buffer corresponding to one particular domain would not affect the traffic in other virtual domains. 
         [0026]    In an embodiment of the invention shown in  FIG. 3 , the daemon processes  305  and  306  aggregate sockets from multiple virtual domains  226  and  227 , thereby reducing the per-domain overhead associated with executing the daemon processes  305  and  306 . In this configuration, when connections from multiple virtual domains are aggregated in the same daemon processes, the daemons  305  and  306  need to be aware of the identity of the virtual domain for which traffic is being processed. In one embodiment of the invention, this is accomplished by examining attributes of the associated socket, and specifically socket identifier (socket_id). Because in the configuration shown in  FIG. 3 , the virtual domain is uniquely identified by the logical or physical interface on the other side of the connection, the virtual domain identification information can be successfully derived from the socket_id resource of the respective socket. 
         [0027]      FIG. 4  illustrates a conceptual block-diagram of a computerized system for processing network content in a virtual domain environment in accordance with an alternative embodiment of the present invention.  FIG. 4  illustrates an alternative embodiment  400  of the invention, wherein multiple daemon processes  405  and  406  are used to distribute the task of processing network content from different virtual domains across multiple available CPU resources  407  and  408 , thus providing performance benefits associated with more even load balancing. The embodiment shown in  FIG. 4  may include a second set of daemons (not shown) for handling a different aspect of content processing. Alternatively, all aspects of content handling may be performed with the shown daemon processes  405  and  406 . 
         [0028]    Additionally, aggregation of services for multiple virtual domains within a single daemon process may require it to frequently access the domain state as well as other configuration information. To this end, the embodiments of the inventive system shown in  FIGS. 3 and 4  include a configuration management server  307 , which provides centralized configuration information, management and update notifications for multiple virtual domains. The configuration server  307  manages configuration for all virtual domains simultaneously and provides application programming interface (API) to answer configuration information queries from any of the daemon applications  305  and  306  on the systems  300  and  400 . 
         [0029]    In the shown embodiment of the invention, the configuration management server  307  references an associated configuration information database  313  storing information on configuration of other modules in the system  300 , parameters global to the system  300 , which are common across multiple virtual domains, as well as information on configuration of each separate virtual domain  226  and  227 . The domain configuration information stored in the database  313  may include the specifics of the content processing policy for that virtual domain. The database  313  may be implemented as an actual database, either local or remote, or, alternatively, it may be implemented as a configuration file or a series of such files. The configuration server  307  may also provide a series of APIs for managing the configuration data stored in the associated configuration database  313 . 
         [0030]    In most cases, the aforementioned configuration database  313  can only be modified through a series of configuration server APIs that provide limited access to the users with reference to their configured permissions. These permissions may be designed to be sufficiently granular. For example, they may be allocated on a per-virtual domain basis. The configuration management server  307  ensures that an administrator for one virtual domain cannot change parameters that affect other disjoint virtual domains. In one embodiment, the internal state of the configuration server  307  is organized in an optimized format that does not store the data for each virtual domain separately. However, the configuration data would still be presented on a per-virtual domain basis at the API level. 
         [0031]    Because different administrators may administer different virtual domains, an embodiment of the inventive system provides for at least one user account in the firewall system with the privilege to add or delete virtual domains. When a virtual domain is added or deleted, all interested applications, such as daemons  305  and  306  in the inventive firewall system (with sufficient privileges), are sent a notification message to notify them of the event. In response to the notification, such applications can then take whatever action is necessary (e.g. add a handler for the new virtual domain or clean up the obsolete virtual domain&#39;s state). When a configuration for an existing virtual domain stored in the database  313  is modified, a similar notification message is also sent to inform interested applications about the change. As it would appreciated by those of skill in the art, because virtual domain may be administered separately, it is desirable that a configuration change in one virtual domain not cause a global action such as a reboot. 
         [0032]    A log server  308  may aggregate log messages from multiple daemons  305  and  306  servicing multiple virtual domains  226  and  227 . Each log message  310  and  312  received from the applications  305  and  306  may either be classified as global, or it may contain an attribute to specify which virtual domain it pertains to. In an embodiment of the invention, the action performed by the log server  308  on each log message (e.g. discarding, storing locally, forwarding to an external server) may be different for each log type as well. In an embodiment of the invention, for future convenience in archiving and storing the logs, log messages pertaining to each virtual domain are stored in separate files. In another embodiment, separate files are utilized to store different categories of logs. Because the number of active log files and sockets may exceed the limit of the operating system, an embodiment of the logging server  308  keeps a table of open file descriptors for each active log file, and closes the file descriptors of inactive log files, as dictated by an Least Recently Used (LRU) algorithm, well known to persons of skill in the art. Specifically, in accordance with the aforementioned LRU algorithm, the embodiment of the inventive system closes the least recently used descriptors first. To this end, the system uses the aforementioned file descriptor table to keep track of which log files were used as well as when the last use took place. In another embodiment, a Pseudo-LRU algorithm is utilized, which employs a probabilistic scheme that almost always discards one of the least recently used items. 
         [0033]    In an embodiment of the inventive concept, daemon processes  305  and  306 , which handle content filtering and/or anti-malware services for multiple virtual domains aggregate all of their virtual-domain associated internal variables into a structure known as a virtual domain state. A daemon process  305  or  306  may create and manage multiple instances of such structure, each corresponding to a different virtual domain. 
         [0034]    A global reference (or pointer) variable for each daemon process  305  and  306  is set to point to the instance of the aforesaid virtual domain state data structure corresponding to the presently active virtual domain. Each entry point into the daemon service process, such as modules that read data from a socket, event notification handlers, signal handlers, etc., update this pointer to the current virtual domain based on an attribute in the received message. Alternatively, the information on the currently active virtual domain may be derived from the message itself, as was described above. For example, in the case of socket descriptors, the daemon process may lookup the identity of the associated virtual domain based on the value of the socket_id variable associated with the socket. 
         [0035]    For added fault tolerance, the daemon process may optionally reset the described current virtual domain reference variable at each exit point. In an embodiment of the daemon module, various functions can access any variables pertaining to an active virtual domain as if they were global variables by using an indirect reference via the aforesaid current virtual domain reference variable. Additionally, the daemon module may provide a set of callback functions to handle creation of a new virtual domain state in response to a virtual domain addition message, removing of a virtual domain state in response to a deletion message, and modification a virtual domain state in response to a configuration change. 
         [0036]    In an embodiment of the inventive firewall system, some daemon processes may act as server processes, forking child processes to handle specific incoming connections. In certain well-known protocols (e.g. PPTP, L2TP, or HTTP), the child process may even fork further processes. In an embodiment of the inventive technique, in order to reduce process overhead on the system, it may be advantageous to aggregate not just the server processes for the virtual domains, but the child processes as well. This is achieved with the use of extra notification messages from the parent process to the child process. When a new session is created, rather than forking a new child process, the parent process may allocate that session to an already existent child. Specifically, the parent encapsulates all initial state parameters into a message that is sent to the child. The child then creates a session state structure, which is analogous to the aforementioned virtual domain state, and processing of multiple simultaneous sessions is accomplished in a described manner. It is not necessary that all sessions from a single virtual domain be allocated to the same child process; however there may often be a performance advantage to doing so. In order to properly distribute the connections among child processes, in one embodiment of the invention, the parent process receives a notification when a session is disconnected, which allows the parent process to track the number of open sessions for each of its children. 
         [0037]    The inventive firewall system may also comprise functionality for handling network content not associated with any of the managed virtual domains. Such out-of-band content includes communications between multiple nodes in a high availability (HA) cluster, communications with network-enabled off-board hardware such as a server chassis management system, or connections from a terminal server. In most cases, traffic from these networks should be kept separate from other network traffic. To avoid mixing the out-of-band traffic with the filtered network content, while still permitting routing, in one embodiment of the invention, a separate virtual domain is provided to contain the out-of-band management traffic. 
         [0038]      FIG. 5  is a block diagram that illustrates an embodiment of a computer/server system  500  upon which an embodiment of the inventive methodology may be implemented. The system  500  includes a computer/server platform  501 , peripheral devices  502  and network resources  503 . 
         [0039]    The computer platform  501  may include a data bus  504  or other communication mechanism for communicating information across and among various parts of the computer platform  501 , and a processor  505  coupled with bus  501  for processing information and performing other computational and control tasks. Computer platform  501  also includes a volatile storage  506 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus  504  for storing various information as well as instructions to be executed by processor  505 . The volatile storage  506  also may be used for storing temporary variables or other intermediate information during execution of instructions by processor  505 . Computer platform  501  may further include a read only memory (ROM or EPROM)  507  or other static storage device coupled to bus  504  for storing static information and instructions for processor  505 , such as basic input-output system (BIOS), as well as various system configuration parameters. A persistent storage device  508 , such as a magnetic disk, optical disk, or solid-state flash memory device is provided and coupled to bus  501  for storing information and instructions. 
         [0040]    Computer platform  501  may be coupled via bus  504  to a display  509 , such as a cathode ray tube (CRT), plasma display, or a liquid crystal display (LCD), for displaying information to a system administrator or user of the computer platform  501 . An input device  510 , including alphanumeric and other keys, is coupled to bus  501  for communicating information and command selections to processor  505 . Another type of user input device is cursor control device  511 , such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor  504  and for controlling cursor movement on display  509 . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. 
         [0041]    An external storage device  512  may be connected to the computer platform  501  via bus  504  to provide an extra or removable storage capacity for the computer platform  501 . In an embodiment of the computer system  500 , the external removable storage device  512  may be used to facilitate exchange of data with other computer systems. 
         [0042]    Embodiments of the present invention are related to the use of computer system  500  for implementing the techniques described herein. In an embodiment, the inventive content processing systems  300  and  400  may reside on a machine such as computer platform  501 . In an embodiment, database  313  may be deployed on a machine such as computer platform  501 . According to one embodiment of the invention, the techniques described herein are performed by computer system  500  in response to processor  505  executing one or more sequences of one or more instructions contained in the volatile memory  506 . Such instructions may be read into volatile memory  506  from another computer-readable medium, such as persistent storage device  508 . Execution of the sequences of instructions contained in the volatile memory  506  causes processor  505  to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software. 
         [0043]    The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor  505  for execution. The computer-readable medium is just one example of a machine-readable medium, which may carry instructions for implementing any of the methods and/or techniques described herein. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device  508 . Volatile media includes dynamic memory, such as volatile storage  506 . Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise data bus  504 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. 
         [0044]    Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, a flash drive, a memory card, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read. 
         [0045]    Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor  505  for execution. For example, the instructions may initially be carried on a magnetic disk from a remote computer. Alternatively, a remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system  500  can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on the data bus  504 . The bus  504  carries the data to the volatile storage  506 , from which processor  505  retrieves and executes the instructions. The instructions received by the volatile memory  506  may optionally be stored on persistent storage device  508  either before or after execution by processor  505 . The instructions may also be downloaded into the computer platform  501  via Internet using a variety of network data communication protocols well known in the art. 
         [0046]    The computer platform  501  also includes a communication interface, such as network interface card  513  coupled to the data bus  504 . Communication interface  513  provides a two-way data communication coupling to a network link  514  that is connected to a local network  515 . For example, communication interface  513  may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface  513  may be a local area network interface card (LAN NIC) to provide a data communication connection to a compatible LAN. Wireless links, such as well-known 802.11a, 802.11b, 802.11g and Bluetooth may also used for network implementation. In any such implementation, communication interface  513  sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. 
         [0047]    Network link  513  typically provides data communication through one or more networks to other network resources. For example, network link  514  may provide a connection through local network  515  to a host computer  516 , or a network storage/server  517 . Additionally or alternatively, the network link  513  may connect through gateway/firewall  517  to the wide-area or global network  518 , such as an Internet. Thus, the computer platform  501  can access network resources located anywhere on the Internet  518 , such as a remote network storage/server  519 . On the other hand, the computer platform  501  may also be accessed by clients located anywhere on the local area network  515  and/or the Internet  518 . The network clients  520  and  521  may themselves be implemented based on the computer platform similar to the platform  501 . 
         [0048]    Local network  515  and the Internet  518  both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link  514  and through communication interface  513 , which carry the digital data to and from computer platform  501 , are exemplary forms of carrier waves transporting the information. 
         [0049]    Computer platform  501  can send messages and receive data, including program code, through the variety of network(s) including Internet  518  and LAN  515 , network link  514  and communication interface  513 . In the Internet example, when the system  501  acts as a network server, it might transmit a requested code or data for an application program running on client(s)  520  and/or  521  through Internet  518 , gateway/firewall  517 , local area network  515  and communication interface  513 . Similarly, it may receive code from other network resources. 
         [0050]    The received code may be executed by processor  505  as it is received, and/or stored in persistent or volatile storage devices  508  and  506 , respectively, or other non-volatile storage for later execution. In this manner, computer system  501  may obtain application code in the form of a carrier wave. 
         [0051]    It should be noted that the present invention is not limited to any specific firewall system. The inventive policy-based content processing system may be used in any firewall operating modes, including, without limitation, Network Address Translation (NAT), routed and transparent modes. 
         [0052]    Finally, it should be understood that processes and techniques described herein are not inherently related to any particular apparatus and may be implemented by any suitable combination of components. Further, various types of general purpose devices may be used in accordance with the teachings described herein. It may also prove advantageous to construct specialized apparatus to perform the method steps described herein. The present invention has been described in relation to particular examples, which are intended in all respects to be illustrative rather than restrictive. Those skilled in the art will appreciate that many different combinations of hardware, software, and firmware will be suitable for practicing the present invention. For example, the described software may be implemented in a wide variety of programming or scripting languages, such as Assembler, C/C++, perl, shell, PHP, Java, etc. 
         [0053]    Moreover, other implementations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. Various aspects and/or components of the described embodiments may be used singly or in any combination in the computerized network content processing system. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.