EP1062785A2 - Systeme et procede reduisant les interactions entre reseaux - Google Patents

Systeme et procede reduisant les interactions entre reseaux

Info

Publication number
EP1062785A2
EP1062785A2 EP99912688A EP99912688A EP1062785A2 EP 1062785 A2 EP1062785 A2 EP 1062785A2 EP 99912688 A EP99912688 A EP 99912688A EP 99912688 A EP99912688 A EP 99912688A EP 1062785 A2 EP1062785 A2 EP 1062785A2
Authority
EP
European Patent Office
Prior art keywords
access
service
node
region
decision
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99912688A
Other languages
German (de)
English (en)
Inventor
Irving Reid
Spencer Minear
Andrew Flint
Gene Amdur
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
McAfee LLC
Original Assignee
Secure Computing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/040,827 external-priority patent/US6453419B1/en
Priority claimed from US09/040,832 external-priority patent/US6182226B1/en
Application filed by Secure Computing LLC filed Critical Secure Computing LLC
Publication of EP1062785A2 publication Critical patent/EP1062785A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]

Definitions

  • the present invention relates generally to network security, and more particularly to a system and method of grouping networks to enforce a security policy.
  • a firewall is a system which enforces a security policy on communication traffic entering and leaving an internal network.
  • Firewalls are generally developed on one or more of three models: the screening router, the bastion host, and the dual homed gateway. These models are described in U.S. Patent No. 5,623,601 to Vu, issued April 22, 1997 and entitled APPARATUS AND METHOD FOR PROVIDING A SECURE GATEWAY FOR COMMUNICATION AND DATA EXCHANGES BETWEEN NETWORKS (Vu), which is hereby incorporated herein by reference.
  • Packet filters are generally host- based applications which permit certain communications over predefined ports. Packet filters may have associated rule bases and operate on the principle of that which is not expressly permitted is prohibited. Public networks such as the Internet operate in TCP/IP protocol. A UNIX operating system running TCP/IP has a capacity of 64K communication ports. It is therefore generally considered impractical to construct and maintain a comprehensive rule base for a packet filter application. Besides, packet filtering is implemented using the simple Internet Protocol (IP) packet filtering mechanisms which are not regarded as being robust enough to permit the implementation of an adequate level of protection.
  • IP Internet Protocol
  • packet filters are executed by the operating system kernel and there is a limited capacity at that level to perform screening functions.
  • protocols may be piggybacked to either bypass or fool packet filtering mechanisms and may permit skilled intruders to access the private network. Accordingly, it is an object of this invention is to provide a method for controlling interactions between networks by the use of firewalls with defined regions.
  • the present invention is directed to a system and method of achieving network separation within a computing system having a plurality of network interfaces.
  • One aspect of the invention is a method comprising the steps of defining a plurality of regions; configuring a set of policies for each of the plurality of regions; assigning each of the plurality of network interfaces to only one of the plurality of regions, wherein at least one of the plurality of network interfaces is assigned to a particular region; and restricting communication to and from each of the plurality of network interfaces in accordance with the set of policies configured for the one of the plurality of regions to which the one of the plurality of network interfaces has been assigned.
  • Another aspect of the invention is a secure server comprising an operating system kernel; a plurality of network interfaces which communicate with the operating system kernel; and a firewall comprising a plurality of regions, wherein a set of policies have been configured for each of the plurality of regions; wherein each of the plurality of network interfaces is assigned to only one of the plurality of regions; wherein at least one of the plurality of network interfaces is assigned to a particular region; and wherein communication to and from each of the plurality of network interfaces is restricted in accordance with the set of policies configured for the one of the plurality of regions to which the one of the plurality of network interfaces has been assigned.
  • a feature of the present invention is the application level approach to security enforcement, wherein type enforcement is integral to the operating system.
  • Still another feature is protection against attacks including intruders into the computer system.
  • Yet another feature is a new graphical user interface (GUI) in effective Access Control Language (ACL).
  • GUI graphical user interface
  • a further feature of the present invention is a visual access control system.
  • Another feature is embedded support for Virtual Private Networking (VPN).
  • VPN Virtual Private Networking
  • Figure 1 depicts an implementation of the firewall of the present invention.
  • Figure la shows a representative computing system protected by a firewall.
  • Figure lb depicts another computing system protected by a firewall.
  • Figure 2 shows the regions and their members as defined in the present invention.
  • Figure 3 is a graphical representation of ACL commands.
  • Figure 4 is a flow diagram for a virus alert.
  • Figure 5 depicts a method by which incoming data packets are processed in accordance with the present invention.
  • Figure 1 depicts a block diagram showing the relationship between a firewall 34 in accordance with this invention, the Internet 36, a Secure Server Network (SSN) 38, a Company Private Net 40, and a Partner Shared Net 42. As shown in Figure 1, communications to and from any other servers or networks goes through the firewall 34.
  • SSN Secure Server Network
  • System 10 in Figure la includes an internal network 12 connected through firewall 14 to external network 16.
  • a server 18 and one or more workstations 20 are connected to internal network 12 and communicate through firewall 14 with servers or workstations on external network 16.
  • System 30 in Figure lb includes an internal network 32 connected through firewall 34 to external network 36.
  • a server 38 and one or more workstations 40 are connected to internal network 32.
  • a server 42 is connected through network 44 to firewall 34.
  • Workstations 40 communicate through firewall 14 with servers or workstations on external network 16 and with server 42 on network 44.
  • network 44 and server 42 are in a sort of demilitarized zone (DMZ) providing protected access to server 42 to internal users and to external entities.
  • DMZ demilitarized zone
  • firewalls 14 and 34 implement a region-based security system as will be discussed below.
  • Regions are a new and flexible way of organizing systems such as systems 10 and 30. Regions let you group both physical interfaces (network cards) and Virtual Private Networks (VPNs) into areas of similar trust and security needs. Regions (along with services) provide the foundation on which every access rule is built. By grouping together networks and VPNs that require the same type of security, you eliminate the need to enter multiple versions of the same access rule for each network or VPN. In doing so, regions give you the flexibility to tailor a security policy that meets the specific needs of your network environment.
  • firewall 34 coordinates communication between internal network 32 (e.g., a company private network), external network 36 (e.g., the Internet) and DMZ network 44 (e.g., a secure server network).
  • firewall 34 also controls virtual private network (VPN) communication between external entities and networks 32 and 44.
  • Regions are defined and one or more networks is assigned to each region.
  • the regions are Sales Office, Worldwide Customer Service, Worldwide Sales, Secure 'DMZ' and R&D Network.
  • R&D Network includes the trusted internal network. Sales Office and Secure 'DMZ' are within slightly less trusted regions.
  • Firewall 34 protects regions from unauthorized access through the use of access rules. For each connection attempt, the Firewall checks it against the defined access rules. The rule that matches the characteristics of the connection request is used to determine whether the connection should be allowed or denied.
  • firewall 34 The operating system on which the firewall 34 is implemented is the BSDI 3.1 version of UNIX, a security hardened operating system with each application separated out, and protected by type enforcement technology.
  • the functions of firewall 34 are all integrated with the operating system, and each one is completely compartmentalized and secured on its own, and then bound by type enforcement control.
  • Type enforcement which is implemented within the operating system itself, assures a very high level of security by dividing the entire firewall into domains and file types.
  • Domains are restricted environments for applications, such as FTP and Telnet.
  • a domain is set up to handle one kind of application only, and that application runs solely in its own domain.
  • File types are named groups of files and subdirectories. A type can include any number of files, but each file on the system belongs to only one type.
  • Type enforcement is based on the security principle of least privilege: any program executing on the system is given only the resources and privileges it needs to accomplish its tasks.
  • type enforcement enforces the least privilege concept by controlling all the interactions between domains and file types. Domains must have explicit permission to access specific file types, communicate with other domains, or access system functions. Any attempts to the contrary fail as if the files did not exist.
  • the type enforcement policy is mandatory, and nothing short of shutting the system down and recompiling the type enforcement policy database can change it.
  • Type enforcement is described in two pending patent applications entitled SYSTEM AND METHOD FOR PROVIDING SECURE INTERNETWORK SERVICES, Serial No. 08/322,078, filed October 12, 1994, and SYSTEM AND METHOD FOR ACHIEVING NETWORK SEPARATION, Serial No. 08/599,232, filed February 9, 1996.
  • a type enforcement scheme provides for the secure transfer of data between a workstation connected to a private network and a remote computer connected to an unsecured network.
  • a secure computer is inserted into the private network to serve as the gateway to the unsecured network and a client subsystem is added to the workstation in order to control the transfer of data from the workstation to the secure computer.
  • the secure computer includes a private network interface connected to the private network, an unsecured network interface connected to the unsecured network, wherein the unsecured network interface includes means for encrypting data to be transferred from the first workstation to the remote computer, a server function for transferring data between the private network interface and the unsecured network interface and a filter function for filtering data transferred between the remote computer and the workstation.
  • the firewall of the present invention features application-level gateways, which negotiate communications and never make a direct connection between two different networks. Hence, unlike packet filtering, which, as described in the prior art, applies rules on every incoming packet of data, the firewall applies rules applicable to the network or port in which data packets are entering.
  • the gateways have a detailed understanding of the networking services they manage. This architecture isolates activity between network interfaces by shutting off all direct communication between them. Instead, application data is transferred in a sanitized form, between the opposite sides of the gateway.
  • the system has been designed to defend against known network penetration and denial of service attacks.
  • the firewall also includes intruder response that allows administrators to obtain all the information available about a potential intruder. If an attack is detected or an alarm is triggered, the intruder response mechanism collects information on the attacker, their source, and the route they are using to reach the system. In addition to real-time response via pager or SNMP, alarms can be configured to automatically print results or to email them to the designated person.
  • Regions are groupings of physical interfaces (network cards) and virtual networks (VPNs) into entities of similar trust.
  • FIG. 2 depicts regions Internet, Secure 'DMZ', R&D Network, Sales Offices, Worldwide Customer Service, and Worldwide Sales.
  • Figure 2 all Sales or Customer Support departments in the company's offices can be grouped together into regions Worldwide Sales and Worldwide Customer Service, respectively.
  • Regions permit the grouping of networks and VPNs that require the same type of security, thereby eliminating the need to enter multiple versions of the same access rule for each network or VPN. Thus regions allow flexibility in tailoring a security policy.
  • the first task is to group together networks or VPNs that require the same type of network access.
  • Each network interface card or VPN that is grouped in a region is considered a member of that region.
  • a region can consist of the following members:
  • userl, user2, user3, mgrl, and mgr2 of Region named R&D Network would have the same rights defined for the R&D Region.
  • Roaming Sales 1, Roaming Sales 2, Roaming Sales 3, etc. would have the same rights accorded to all members of Region named Sales Offices.
  • userl, user2, Roaming Sales 1, Roaming Sales 2, mgrl, etc. do not necessarily represent only workstations. In other words, it is possible for user2 to logon the workstation onto which user3 might ordinarily logon, or for mgrl to logon the workstation onto which mgr3 might ordinarily logon.
  • Every region is protected from every other region as defined in the firewall of the present invention. All connections to and from each region are first examined by the firewall. Regions may communicate with each other only if an appropriate access rule has been defined. For each access rule, first, the services that the rule will control must be defined, then, second, the regions that the connection is traveling between must also be defined. For example, if the Internal region is to be allowed to access Telnet services on the Internet region, the access rule must specify Telnet as the service that the rule controls and specify the From: region as Internal and the To: region as Internet. Hence, the firewall of the present invention does not allow traffic to pass directly through the firewall in any direction. Region to Region connections are made via an application aware gateway. Application-level gateways understand and interpret network protocol and provide increased access control ability.
  • the ACLs are the heart and soul of the firewall. For each connection attempt, the firewall checks the ACLs for permissions on use and for constraints for the connection. Constraints can include: encryption requirements, authentication requirements, time of day restrictions, concurrent sessions restrictions, connection redirection, address or host name restrictions, user restrictions and so forth.
  • Access rules are the way in which the firewall protects regions from unauthorized access. For each connection attempt, the firewall checks it against the defined access rules. The rule that matches the characteristics of the connection request is used to determine whether the connection should be allowed or denied.
  • access rules are created in a completely new way - using decision trees. Knowing that an access rule is based on a series of decisions made about a connection, the firewall permits the building of an access rule based on "nodes" of decision criteria.
  • a node can be added to check for such criteria as the time of day, whether the connection uses the appropriate authentication or encryption, the user or groups initiating the connection request or the IP address or host of the connection.
  • Each node is compared against an incoming connection request and you determine whether the connection is allowed or denied based on the results of the node comparison. Every access rule must consist of two specific nodes. The first, the Services node, decides which service(s) the rule will control. The second, the From/To node determines the source region and destination region of the connection. Once the services and regions for the rule are established, more nodes can be added to determine specific details about the connection.
  • the Firewall presents access rules as visual decision tree diagrams. Each diagram contains building blocks or nodes of information that apply a condition to or make a decision about the connection. At any point, you can add alerts to indicate when a particular point in an access rule has been reached or filters to check for authentication, encryption, WWW blocking or FTP commands. In addition to the Allow or Deny terminal nodes, there are four other types of nodes you can add to an access rule: decision nodes, filter nodes, redirects and alerts. Decision nodes will be discussed next.
  • the Firewall determines whether the connection is true or false. If the connection meets the criteria listed in the node, the connection is considered true and proceeds along a "true" branch. If the connection does not meet the node criteria, the connection is considered false and proceeds along a "false" branch.
  • the filter node can force user authentication or encryption, can use filters to block particular WWW connections, or can filter the connection to see if it contains Java or ActiveX content.
  • a rewrite node is a point in an access rule where source or destination addresses are mapped to other source or destination addresses. Destination IP address rewrites allow an inbound connection through NAT address hiding to be remapped to a destination inside the NAT barrier. Source address rewrites can be used on outbound connections to make the source appear to be one of many external addresses. This process allows the internal hosts to be aliased to external addresses. In one embodiment, rewrites can be based on any connection criteria, including users.
  • connection request When a connection request reaches a node in a rule, it is checked against the information in the node. If the connection is a filter node 72, the filter condition is either applied or ignored. Only one branch leads out of a filter node. If the node happens to be a decision node, there are two possible results. If the connection meets the criteria listed, it is considered true and follows the "true" branch of the access rule. Otherwise, the connection is considered “false” and follows the false branch. Referring to Figure 3, the design for this feature falls almost directly out of the GUI representation.
  • the GUI presents access rules as a decision tree with special kinds of nodes which make true or false decisions. Each decision leads to a branch which contains more nodes. Along the way, filters can be acquired.
  • the firewall's access flow diagrams allow any decision criteria to be based on any other decision, in any order. If the administrator wants to check user first, then time, then apply a specific access policy, they can. In addition, the flow diagrams are object oriented for greater power.
  • Access control rules on the firewall can be defined with flexibility previously unknown in the industry. This allows, for example, for different web filtering polices on a per-user basis, the ability to deny a connection if it isn't encrypted, authenticate a connection by strong token and another connection by password. Access rules can incorporate any of the following criteria:
  • Source and destination addresses, networks, hosts, and domains • Type of service • Type of service (WWW, Email, Telnet, FTP, etc.)
  • Source and destination service port and IP address rewrites
  • the firewall's access control diagrams include the capability of IP address rewrites, which allows a connection inbound through NAT address hiding to be remapped to a destination inside the NAT barrier. Also, rewrites can be used on outbound connections to make the source appear to be one of many external addresses. This allows internal hosts to be aliased to external addresses.
  • Rewrites can be based on any connection criteria, including users. So the administrator can have anonymous FTP connections directed to a public access FTP server on the Secure Server Net, but remap users to their internal machines.
  • the firewall's access control diagrams also include the capability of sending alerts, with an administrator-defined message, based on any connection decision. Alerts can be dropped into the access flow diagrams at any point. If a connection reaches that point in the diagram, the alert is triggered. For example, in Figure 4, a check for viruses is performed on a file (70). If a virus is found, the administrator is alerted (72), and the transfer is redirected to a safe location for later inspection (74).
  • the ACLs consist of all the required kernel code. This is all the code that implements the rules themselves in the kernel including: build, modifying, deleting, and querying the rules. Also included are the system calls that the user level programs need to use the ACLs.
  • the ACLs themselves must satisfy the requirements laid out by the GUI design. This dictates to a large degree how the rules must be implemented. Since the user has no direct access to the ACLs (rather they use the user interface), there are no ease of use concerns here except to say that the ACLs must be something the developers can work with easily. Hence, there exists a good set of tools to debug the ACLs.
  • VPN Virtual Private Networking
  • Every access control is available to VPN connections in exactly the same way as for physically connected networks: user controls, IP restrictions, protocol filters, address hiding, multi-homing, and more.
  • VPN is a method of authenticating and transparently encrypting bi-directional data transmissions via the Internet. Both gateway to gateway network links as well as roaming users on VPN enabled laptops are utilizing the security and cost effectiveness of VPN Internet encrypted communications.
  • VPN technology is embedded in the core design of the firewall of the present invention.
  • Each socket has two endpoints, so there can be up to four different IP addresses.
  • loc_dst_addr could be anything, if the firewall bound to a wildcard address.
  • client_sock server_sock client (cli_addr) > [firewall (invention) ] > (srv_addr) server
  • the SIGWINCH signal is used to force all ACLs to be rechecked and for proxies to re-initialize themselves (for proxies that use config files). Most proxies will handle this signal themselves, but if secured did an ACL before starting a proxy, it must also do the recheck.
  • the SIGWINCH signal will come from the backend, which will use killpg() to signal all the inetd daemons, secured processes, and their child proxies or servers. Note that the default action for SIGWINCH is ignore, so inetd did not need to be modified.
  • Some transient proxies use the SIGALRM internally to do idle proxy timeouts (tcpgsp, tnauthp, sqlp).
  • proxies should shutdown cleanly if given a SIGTERM signal.
  • the backend uses SIGTERM to kill inetd processes when the last service has been removed.
  • Squid will re-open (not rotate) its logfiles if given the SIGUSR1 signal, and re-initialize itself if given SIGWINCH or SIGHUP. Note that this means squid does not do ACL rechecks, it treats it just like a SIGHUP - closes its listen sockets and waits 30 seconds for active sessions to terminate, then re-opens listen sockets. This easy way out was chosen because squid's connections are relatively short-lived.
  • proxy idle timeout as N seconds (transient only)
  • inetd.conf lines are much simpler and the degree of control is much greater.
  • BFS inetd.conf entries for inbound proxies inbound_udp_relay -e 199.71.190.101 -w 65546 -u g_udp_ir -d 192.168.128.138 -m -g 0 secured -ws 144 -wr 1 -wn 1 -1 199.71.190.121 www_X www_r_i - - -d 192.168.125.2 -m
  • non-transparent proxy mode only works for VDO-Live -U user iame set the user name (ftp ftp_mux and ftpp/ftpd)
  • ch s for syslog
  • ch a for audit
  • ch e for stderr
  • the firewall of the present invention uses new structured audit calls for session logging, which include src and dst region, ACL matched, auth method, encryption state, etc.
  • the new calls are:
  • audit_session_end • audit_log_ftp - to log FTP file transfers, includes user, filename, size audit_log_smartfilter - to log URL, action (allow/deny), blocked categories
  • the present firewall has incorporated the proxy-warder-interface (pwif) from Sidewinder.
  • pwif proxy-warder-interface
  • the pwif interface was already supported by tnauthp, we added pwif support to ftpp, and for GUI login.
  • the backend will have to keep the squid passwd file in sync with the static-passwd file used for ftp and telnet.
  • ACLs also return the following: from_region, to_region, destination redirects for IP and port, source redirects for IP and port, transparency settings and filters.
  • ACL filters as follows (example from acl_util.h): #defme FILT_DELIM T
  • the caching WWW proxy (squid) is very interesting because it has its own ACL checks and non-blocking DNS interface. We leveraged this built-in support in our work, but it was still tricky to integrate the firewall's ACL calls while operating as a non-blocking long-lived proxy.
  • the proxy might not get an authentication filter after the ACLs return NEEDS J SERNAME, the squid proxy-auth code has been changed to not return a failure code if the password was not accepted. Instead we save some internal state, and only check this state if an authentication filter is returned later.
  • the proxy will make two calls to the ACLs. The first will be: int scc_is_service_allowed( unsigned long service_number, struct sockaddr_in *src_ip, struct sockaddrjn *dst_ip, char *src_host_name, /* usually null */ char *dst_host_name, /* usually null */ char *user_name, /* null if none */ int name_valid, /* tell if name is valid */
  • service_number this is a number that the backend decides and is unique per service or possibly per service, from and to region triplet as desired.
  • src_ip this is the source IP address of the connection.
  • dst_ip this is the destination IP address of the connection.
  • src_host_name this is the host name based on the reverse lookup of the source address of the connection. This is generally only used when the kernel explicitly asks for it by returning from a previous call to scc_is_service_allowed with a return value of ACL_RESOLVE_SRC_ADDR.
  • dst_host_name this is the host name based on the reverse lookup of the destination address of the connection. This is generally only used when the kernel explicitly asks for it by returning from a previous call to scc_is_service_allowed with a return value of ACL RESOLVE ' DST ADDR.
  • user_name this is the user name of the person using the service. This value is only used when ACL_NEED_USER_NAME has been returned by the kernel. Use NULL, if the name has not yet been requested. Currently only FTP, telnet and WWW support user names.
  • name_valid this tells the ACLs whether or not a user name makes any sense for this protocol. If the name yalid flag is set to TRUE, then user decision nodes will be used (and thus a user name will be required if a user decision node is encountered when checking the ACL). If set to false, then the user decision nodes will be ignored and the true path of those nodes encountered when checking the ACL will be used.
  • to_region the region number that the destination address of this connection is in.
  • filter_text_len this is a pointer to an integer which has the length of the filter Jext array in it. This value will be set to the amount of data returned by the access call on return. If the return value is
  • rule_name_len this is the size of the array rule iame.
  • rule_name this is the name of the rule that allowed or denied the connection. Only a maximum of rule iame Jen - 1 characters will be stored in there.
  • redirect_dst_addr_port this is the address and port to redirect this connection to.
  • the system will set this to all zeroes if it is not in use.
  • the port and address will always both be set together in this structure if it is to be used. Only the sin jort and sinj ddr part of the structure will be used.
  • redirect_src_addr_port this is used to indicate to the firewall that when making the connection from the firewall to the destination, it should use the source address/port provided. Note that unlike the redirect _dst_addr_port field only the parts of the address required will be filled out. In particular, if the port is specified but not the address then the address field will be zero. Similarly, if the address is specified but not the port, then the port will be zero. For the redirect _dst_addr )ort, if one or both field are specified then they are both returned (with the unspecified field left the same as the actual destination).
  • master_key this is the key that indicates which items have been licensed on the firewall.
  • connection_id this is the connection id for this connection.
  • connection_id this is the connection id for this connection.
  • the user name will be used by the system to get the groups automatically behind the scenes in the library call. This means that the actual call to the kernel will have more fields. In particular, there will be a list of group names and a counter to indicate how many elements are in the list.
  • the second call will be: int scc_service_done(caddr_t connectionjd);
  • proxies When an ACL is updated, proxies have to recheck their connections to see if they can still make the connection. This is done as follows: int scc_recheck_service( unsigned long service number, struct sockaddr_in *src_ip, struct sockaddrjn *dst_ip, char *src_host_name, /* usually null */ char *dst_host_name, /* usually null */ char *user_name, /* null if none */ int name_valid, /* tell if name is valid */ caddr_t &connection_id /* id for this connection */ /* return values */ int &to_region; int &from_region; int &f ⁇ lter_text__len, char &filter_text, int rule_name_len, char &rul
  • connectionjd is passed in as a parameter not a return value. If the connection is not allowed, then the counters are automatically freed up and the proxy need not make any further calls for that connection. In the case of counter nodes, the recheck will fail until the counter is at an acceptable level. This means that, if the counter has been decreased below current connection levels, the first connection rechecked will fail and so on until the current number of connections counter has been decremented enough. Thus, proxies should recheck services in order of lowest priority to highest priority (typically by checking the oldest sessions first, when that is possible). Note that short-lived proxies and servers started by secured cannot guarantee the order in which ACLs will be rechecked, since they will all get a HUP signal at the same time.
  • rgnbind() allows a service on the firewall to listen for network connections only in the specified region. This allows us to have different programs listening in different regions; for example, a caching WWW proxy for connections from internal to external and a non-caching proxy from SSN to external.
  • network servers were modified to use rgnbind() instead of bind(), to ensure that they handled traffic for the correct region.
  • rgnctl() adds, deletes, and modifies regions and sets per-region parameters: Members, router, connection refused, and ping response.
  • rrctl() sets region-to-region policy. Currently only handles network address translation, but could add other parameters in future.
  • scc_getregion() retrieve the region number for a given IP address scc_service_checks() scc_backend_acl_calls() scc_service_done() scc_get_service_counts()
  • Other changes include:
  • step 80 when a packet is received as shown in step 80, the region ID is retrieved from the network interface and assigned to the packet in step 82. It is determined in step 84 whether the packet is encrypted, i.e., a VPN. If the packet is encrypted, processing proceeds to step 86 where the VPN security association for that packet is retrieved. The packet is then decrypted in step 88, and the previously stored region ID for that packet is replaced with the region ID of the VPN in step 90. All further operations take place on the decrypted packet.
  • the packet is encrypted, i.e., a VPN. If the packet is encrypted, processing proceeds to step 86 where the VPN security association for that packet is retrieved. The packet is then decrypted in step 88, and the previously stored region ID for that packet is replaced with the region ID of the VPN in step 90. All further operations take place on the decrypted packet.
  • a UNIX system checks whether the packet is destined for one of the firewall's IP addresses. If not, the packet is forwarded to the real destination. This has been modified in SecureOS to check that: (a) the destination is in the same region as the source and (b) the "router" flag is set for that region, as shown in steps 92 and 94. If either condition is not met, the packet is not forwarded, as shown in step 102.
  • step 96 the system looks for any socket listening for the incoming packet. Traditionally this match looks at source IP address, source IP port, destination address, and destination port. This has been extended in SecureOS, as shown in step 98, to also check the region associated with the packet against the region specified in the rgnbind() system call, to ensure that sockets receive data originating only from the correct region. If all conditions are met, the packet is forwarded in step 100; otherwise, the packet is not forwarded (step 102).
  • This fo lowing example sets up three regions: internal, external, and Secure Server Net (SSN):
  • the following example shows a region of the firewall of the present invention configured to sit between two departments of a company and transparently filter and control network access between the departments.
  • the two regions can see each others' IP addresses; that is, no address translation is done. Nevertheless, network connections are only allowed if an access rule on the firewall grants permission.
  • the ACLs described above combine the services themselves, the regions that the services bridge, and the access control decisions.
  • the user draws a graph which starts with a service and a to-from set.
  • the user creates a path consisting of the desired options which can include: time, session counts, authentication, encryption, users/groups, WWW filters, ftp filters, email filters, destination address re-writes, to addresses and from addresses.
  • the user is building a decision tree. In the embodiment shown, some of the decision nodes in the tree have two paths from them to the next node (a true path and a false path) and some just have one path.
  • the nodes that have one path are nodes which provide filtering, logging, or address rewrites.
  • each node in the decision tree can be one of two types of node.
  • the first type is a decision node.
  • the second type of node is a filter node.
  • a decision node is one where the decision regarding the action to perform is done in the kernel. To the user, on the GUI, it means that they can have a true branch and a false branch. This node is implemented in user space in the service itself. A filter node is implemented in user space in the service itself. The service will ignore filters which do not apply to it. To the user, on the GUI, it means that they can only have a trwe branch. The false branch is always a deny service.
  • the sec decision node is a union structure that looks like this:
  • nodejype is one of:
  • the nodejype indicates if a permit or deny is to be used.
  • subrulejptr is to implement the rule within a rule requirement of the GUI.
  • the node_descriptor is a character string which describes this particular node. There is no set definition for this description so the backend is free to enumerate nodes as it wishes and the GUI/backend can use node descriptors to glue together messages from the audit stream to trace through what is happening in the decision process. Also we use the node descriptor as an index into a the node table. This table has as entries a pointer to each node for fast node lookup. If a node is deleted, then the nodeJ ⁇ asJbeen_deleted flag is set. If at any point in a ACL check we come across such a node we issue a deny. We use the reference ount to determine if we actually delete the node. Only when the reference count is zero do we actually free up the memory.
  • the debug jiode flag can be set to do various things as will be discussed below. We use the loop home flag to prevent loops in the ACLs causing us to recurse forever. We set this flag to true when we enter this node for checking and after checking the children to the end we reset the value to false. If while checking the children we encounter a loop flag set to true we know we have reached cycle in the tree.
  • the Services node and regions node are special decision node which anchor the decision tree. This allows for quick indexing by service number. To do this, there will be an array of pointers ( scc_service ⁇ rray) indexed by the service number. The pointers point to and array of regions used by that service. There will be a variable max service number which the kernel will maintain to use as a guild line for indexing into the service array.
  • Each entry in the scc ervice_array will be a structure as follows:
  • Each service should have a unique number but this will not be implemented in the kernel. Rather, the kernel will be given a service number and the kernel will allocate a bucket for that service. The kernel will be unconcerned about which service this bucket actually belongs to. Note that the scc ervice ec is not a part of the scc_decisionj ⁇ ode listed above.
  • scc_service_rec ⁇ int number_regions ; unsigned long total_sessions; unsigned long current sessions ; scc_decision_node *next_decision; char *node_descriptor; scc_service_def *parent_struct ; int to_region; int from_region; int debug_node ; int node_has__been_deleted;
  • the decision is trwe. If one of the groups that the user belongs to (also included in the system call) is in the array of users, then the decision is true. Note that users and groups are one and the same as far as the system goes. This means the GUI/backend must make sure that there is not a group called Andrew and a user called Andrew.
  • the IP Addresses/Host Names decision node is used to make decisions that select for/against source or destination addresses or host names.
  • the Maximum Concurrent Sessions decision node provides the ability to put a choke on the number of concurrent sessions on a service or group of services. We want to have the ability to program a counter to be shared among all the services on this path, or to have the counter count for each service individually.
  • the shared count record is used. Otherwise, the array is used. Note the size of the array is stored in num ervices and the array is indexed as:
  • the node asj een_deleted tells a process that is going to decrement the counter whether this node is being used or not. If set to false, then the record is in use and increments or decrements are done accordingly. If set to true, then when the count gets decremented to zero, the memory is freed up and the parent's reference counter is decremented. If the parent has been deleted and if the reference counter is set to zero then the parent node is freed.
  • the node has _been_deleted flag, in the detailed record, gets set to true (i.e. not zero) when the node itself goes away (the user has removed it from the diagram) or if the counter is switched from individual to shared service counts. Note that each counter is indexed by to region and from region so that the count is unique on a service-from region-to region triplet.
  • the parent jecord pointer points back to the top level scc lecisionjtode.
  • the service jiumber is there so that we can index into the service ounters array and set the array pointer to NULL when we are preparing to free up memory.
  • the sccjlatejec is the top level structure and it has number ⁇ details separate date rules. Each of those rules are in a scc_datejletailjec. So, we have an array of structures in sccjlatejec each of which has a start seconds and an end seconds value. Each value is relative to the beginning of Sunday. Thus, start second 0 and end second 1 would be allowing the connection only during the first second of Sunday. The backend must provide the records in sorted order by start second.
  • a time and date decision is based on a series of time rules. We simply check the current time and day against each rule. If we find a rule where the current time and day falls in that rule, then the decision is the true path otherwise it is the false path.
  • a rule must consist of at least a services node and a region node and have all true and false branches terminated by terminal nodes. If you plan to use a segment of a particular rule in more than one rule, you can create a partial rule. Partial, or shared, rules can be added to any complete rule.
  • complete or partial access rules can be configured using a graphical user interface such as is shown in Fig. 3. In order to configure a complete or partial rule one must perform the following general steps:
  • a rule is simply a chain of decision nodes. After the chain of rules is completed, the decision path at the entry point to the sub-rule is taken based on the outcome of the rule. The filters and audit messages within the rule are still generated and accumulated.
  • Log nodes direct the kernel to log messages to the audit subsystem.
  • the backend can fully specify the message to log.
  • the structure is as follows:
  • audit_printf (audit_message_type, AUDIT_A_AREA, AUDIT_T_NETACL, AUDIT_P_MAJOR, "%s from ACL log node: %s", node_descriptor, audit_message) ;
  • filters are just strings which the proxy interprets to perform it's filtering.
  • the kernel does none of the decision work. Instead, the kernel is given a pattern, and if the node is reached and if there is some data for the decision made at that node, then the pattern is accumulated as a filter. All of the filters are accumulated by the kernel, concatenated together and returned to the proxy as part of the system call. In such an embodiment, the kernel requires no work to implement filters beyond the re-writing of addresses.
  • a filter structure contains all the relevant filter data. The following shows the data and explains its use: struct scc_filter_rec ⁇ char *filter_string; int filter_string_length;
  • the filters are as follows: encryption, authentication,
  • the encryption filter requires that a connection is encrypted with a certain level of encryption. It will be up to the user level process to verify that the requirements of the filter are met. If the requirements are not met the action is to deny the connection.
  • the authentication filter requires that a connection is authenticated.
  • One or more possible methods of authentication can be specified. This would only apply to those protocols that allow for a user name as part of the protocol. Currently this would be: ftp, telnet, and WWW.
  • SmartFilter can be used as described above.
  • a WWW filter may block Java or ActiveX scripts.
  • the SmartFilter filter can also specify which policy to use (for sites that define multiple policies). These are performed by the caching WWW proxy only.
  • One such embodiment also includes cookie blocking.
  • FTP Filters there are a number of possible FTP Filters. These include filtering on: GET, PUT, PASV, PORT, MKDIR, RMDIR, RENAME, DELETE, SITE, filtering on file size and filtering anonymous ftp. All filtering must be done by the proxy or server.
  • Redirect nodes act like filters since they only have one path out of them.
  • Redirects are tables which map source or destination addresses to other source or destination addresses. Currently we only map destination addresses. The most obvious use of redirects are to map connections coming into the firewall from the insecure side of a NAT region pair to a secure machine. In this case, the connecting host cannot see the hosts behind the firewall. The redirects will map a connection coming to a given firewall address (could be one of many because of MAT) to the desired secure host. The kernel will only accept addresses (the UI can accept names providing it translates them to an address).
  • the tables whose structure is described below, will contain an entry for each MAT address that applies.
  • redirects Another use of redirects is to map an address going from a region which can see all the hosts in the destination region. In this case, the redirect has only one entry which maps the address and port to the given address and port.
  • the final case is one where we might not know which of the above two apply. In that case, all possible MAT addresses might be present and a global rule in the case that the connection is not to the Firewall itself, is also present. This final case happens when you are using a redirect from a rule within a rule.
  • the structure for the redirect table is as follows:
  • the nodejype is one of:
  • ACL_SRC_RE RITE_NODE ACL DST REWRITE NODE Since the number of addresses to check against are minimal, we will leave the addresses in unsorted order.
  • the redirect mapping goes as follows:
  • a port number of 0 means any port and an address of 0.0.0.0 means any address.
  • One embodiment supports netmasks in the kernel. Such an embodiment masks the address to check with the netmask and check to see if it is the same as the check_addr. If so (and providing there is a port match) we have a match.
  • MAT nodes that handle MAT address on a single region interface.
  • the GUI system allows the user to configure different behaviors depending on which address the connection came to the firewall on. To handle this the backend needs to put a MAT node as the node the service points to for those regions that have MATs. For example, if the user enables a service From “ region 1 " to To " Firewall via address a ", then a MAT node is needed. We only need MAT nodes for the firewall region provided that MAT has been defined for the firewall in that region.
  • a hash table that stores pointers to the decision nodes.
  • the hash table consists of pointers to linked lists. The string is hashed to a bucket in the table and each bucket is the start of a linked list. A node when added to the table, the table is checked to see if the name is unique by looking at the string in the linked list that the string hashes to. If it is unique, then the node is added to the front of the hash table and if the node is already present, an EEXTST error is returned.
  • the hashing algorithm used is the sum of the characters in the name modulo the size of the table.
  • the table is static in size and is set to ACL JIASHJT ABLE _SIZE (i.e. 200 buckets).
  • Counters need to be kept consistent (i.e. correct) even when a process that holds a connection dies. There are several ways to do this.
  • the current approach is to use the proc structure of the process making the system call. A new field will be added to keep track of each counter used by that process and the number of concurrent uses of the counter. When the process dies, then the exitl code in the kernel will go through and clear the counters and free the proc space.
  • a node as_been_deleted flag. This flag is part of every counter and is set to true (i.e. not zero) if the counter is no longer in use and zero otherwise. If a process decrements a current count to zero and if the flag is set to true, then the memory is freed since no process is using that memory. If a flag is set to true and the current count is already zero, then the memory is freed up immediately.
  • the entry in the proc structure is: scc_ACL_cell *scc_ACL_head; Each cell in this linked list is as follows:
  • connection id passed back to the proxy will be the actual pointer to the scc_ACL_cell.
  • the proxy does its free, we can very easily free up the counter space, free the memory, and re-attach the linked list of connection information.
  • the proxy will make two calls to the ACLs.
  • the first call is:
  • int scc_is_service_allowed ( unsigned long service_number, struct sockaddr_in *src_ip, struct sockaddr_in *dst_ip, char *src_host_name, /* usually null */ char *dst_host_name, /* usually null */ char *user name, /* null if none */ int name valid, /* tell if name is valid
  • the possible return values are:
  • ACL_DENY 0 #define ACL_ALLOW_HIDE_SRC 1 #define ACL_ALLOW_HIDE_DST 2 #define ACL_ALLOW_HIDE_BOTH 3 #define ACL_ALLOW_SHOW_ALL 4 #define ACL_RESOLVE_SRC_ADDR 5 #define ACL_RESOLVE_DST_ADDR 6
  • service_number this is a number that the backend decides and is unique per service or possibly per service, from and to region triplet as desired.
  • src_ip this is the source IP address of the connection.
  • dst_ip this is the destination IP address of the connection.
  • src_host_name this is the host name based on the reverse lookup of the source address of the connection. This is generally only used when the kernel explicitly asks for it by returning from a previous call to sccjs ervicejxllowed with a return value of ACL RESOLVE SRC ADDR.
  • dst host name this is the host name based on the reverse lookup of the destination address of the connection.
  • ACL RESOLVE DST ADDR This is generally only used when the kernel explicitly asks for it by returning from a previous call to sccjs ervicejxllowed with a return value of ACL RESOLVE DST ADDR.
  • user name this is the user name of the person using the service. This value is only used when ACLJNEED JSERjNAME has been returned by the kernel. Use NULL, if the name has not yet been requested.
  • FTP, telnet and WWW support user names. name valid: this tells the ACLs whether or not a user name makes any sense for this protocol. If the name_yalid flag is set to TRUE, then user decision nodes will be used (and thus a user name will be required if a user decision node is encountered when checking the ACL).
  • to_region the region number that the destination address of this connection is in.
  • fromj-egion the region number that the source address of this connection is in.
  • filter text len this is a pointer to an integer which has the length of the filter Jext array in it. This value will be set to the amount of data returned by the access call on return. If the return value is ACLjNEED_MORE_FILTER_SPACE, then the value in this variable will contain the amount of space required, filter text: this is an array of characters of size filter jext Jen which will be used to store the concatenated filter strings accumulated while checking the ACLs.
  • rule name len this is the size of the array rule ame.
  • rule_name this is the name of the rule that allowed or denied the connection. Only a maximum of rulejiame Jen - 1 characters will be stored in there.
  • redirect_dst_addr_port this is the address and port to redirect this connection to. The system will set this to all zeroes if it is not in use. The port and address will always both be set together in this structure if it is to be used. Only the sin_port and sin_addr part of the structure will be used.
  • redirect_src_addr_port this is used to indicate to the firewall that when making the connection from the firewall to the destination, it should use the source address/port provided.
  • redirect jlstjxddrjport field only the parts of the address required will be filled out. In particular, if the port is specified but not the address then the address field will be zero. Similarly, if the address is specified but not the port, then the port will be zero.
  • master_key this is the key that indicates which items have been licensed on the firewall.
  • connection id this is the connection id for this connection. When the service is finished you provide this id to the scc ervice done system call and that function decrements the correct counters.
  • the user name will be used by the system to get the groups automatically behind the scenes in the library call. This means that the actual call to the kernel will have more fields. In particular, there will be a list of group names and a counter to indicate how many elements are in the list.
  • the second call will be:
  • proxies have to recheck their connections to see if they can still make the connection. This is done as follows:
  • int scc_recheck_service ( unsigned long service_number, struct sockaddr_in *src_ip, struct sockaddr_in *dst_ip, char *src_host_name, /* usually null */ char *dst_host_name, /* usually null */ char *user_name, /* null if none */ int name valid, /* tell if name is valid caddr_t &connection_id /* id for this connection */
  • connectionjd is passed in as a parameter not a return value.
  • proxies should recheck services in order of lowest priority to highest priority (typically by checking the oldest sessions first, when that is possible). Note that short-lived proxies and servers started by secured cannot guarantee the order in which ACLs will be rechecked, since they will all get a HUP signal at the same time.
  • the backend is able to add, change, delete decision nodes. It also is able to insert new nodes into the tree. In such an embodiment, the following functions are provided to allow this to be done efficiently. All backend calls return 0 for success and -1 for failure. Later, errno will be used to determine what went wrong.
  • the Adding New and Updating Nodes call is used to add or update a node.
  • the same call is used to add a new node or update a node. If the node_descriptor is unique, then it is a new node, otherwise update the node. In both cases, the values must all be completely filled out.
  • int scc_set_host_node ( char *node_descriptor, int type, /* src or dst check */ char **sorted_hostname_array, /* see below */ int number_of_names, struct sockaddr_in *ip_addr, /* array of structs of ip addrs */ struct sockaddr_in *ip_mask, /* array of structs of ip masks */ int number_of_ip, char *true_child_node_descriptor, char *false child_node_descriptor) ;
  • rafael.tor.securecomputing.com would be moc.gnitupmoceruces.rot.leafar. These are then put into sorted order. This allows the kernel to quickly process wild card entries. It is also important that unneeded entries are not loaded into the kernel. For example if the user has specified *.com, then no other entries of the form .com should be present in the list passed to the kernel.
  • int scc_set_count_node char *node_descriptor, int service_specific_flag, /* share or not */ int max_count, char *true_child_node_descriptor, char *false_child_node_descriptor) ; int scc_set_time_node ( char *node_descriptor, scc_date_detail_rec *date_entries , int number_date_entries, char *true_child_node_descriptor, char *false_child_node_descriptor) ;
  • date records must be in sorted order using start econds as the key to sort on.
  • date ntries field is an array of structs.
  • int scc_set_mat_node int num_mat_addrs , struct sockaddr_in *mat_addrs, /* array of structs */ char **node_descriptors
  • the two arrays must be in sync (i.e. the first MAT address uses the first decision node in the node descriptors array).
  • ENOMEM happens when the kernel is out of memory.
  • ENOENT happens when the node descriptor specified does not exist.
  • ELNVAL happens when an invalid argument is provided to a system call. One example is if a NULL true hild odejlescriptor is passed in as an argument.
  • int scc_set_service_node (unsigned long service_number, /* made up by backend */ int to_region, int from_region, char *node_descriptor, int node_debug, char *child node descriptor) ;
  • the service nodes are different from the other nodes.
  • the reference is the service number not the node descriptor.
  • the node descriptor is there for audit purposes and should be the name of the ACL rule. If a debug value is set here then debugging is turned on recursively down the tree.
  • the descriptor to use for the allow terminating node is the string _SCC_ALLOW.
  • the string JSCCJDENY For all nodes, the descriptor to use for the allow terminating node is the string _SCC_ALLOW.
  • the string JSCCJDENY For the deny connection terminating node, use the string JSCCJDENY.
  • Nodes are linked in the same system call that they are built or updated from. Those nodes which only have one path through them only have one potential node leaving them.
  • a child node can either be, a descriptor of an existing node, the string _SCC_ALLOW, or the string SCCjDENY.
  • SCC LLLOW and SCCjDENY are the accept and deny terminals of the tree respectively and otherwise the child is another scc_decisionj ⁇ ode.
  • int scc_delete_service ( int service_number, int to_region, int from_region) ;
  • int scc_set_debug ( char *node_descriptor, int debug_value) ;
  • the ACLs keep track of service counts for all services that use them.
  • the counts are by service number, from region, to region triplet. Because we do not know before hand how many services there will be we implement this function in a two call method.
  • a system call which could be used is as follows:
  • int scc_get_service_counts ( int calltype int *count_size, struct sec serv count *counts]
  • the calltype can be one of:
  • Each entry in the counts array is defined as follows:

Abstract

On utilise un coupe-feu pour assurer la séparation entre les réseaux d'un système informatique à plusieurs interfaces de réseau. On établit à l'intérieur du coupe-feu une série de zones, et on configure un ensemble de règles pour chacune desdites zones. Le coupe-feu restreint les communications entre les différentes interfaces en fonction de l'ensemble de règles configuré pour l'une des zones à laquelle l'une des interfaces de réseau a été attribuée.
EP99912688A 1998-03-18 1999-03-18 Systeme et procede reduisant les interactions entre reseaux Withdrawn EP1062785A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US09/040,827 US6453419B1 (en) 1998-03-18 1998-03-18 System and method for implementing a security policy
US09/040,832 US6182226B1 (en) 1998-03-18 1998-03-18 System and method for controlling interactions between networks
US40827 1998-03-18
US40832 1998-03-18
PCT/US1999/005991 WO1999048261A2 (fr) 1998-03-18 1999-03-18 Systeme et procede reduisant les interactions entre reseaux

Publications (1)

Publication Number Publication Date
EP1062785A2 true EP1062785A2 (fr) 2000-12-27

Family

ID=26717487

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99912688A Withdrawn EP1062785A2 (fr) 1998-03-18 1999-03-18 Systeme et procede reduisant les interactions entre reseaux

Country Status (2)

Country Link
EP (1) EP1062785A2 (fr)
WO (1) WO1999048261A2 (fr)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU7867000A (en) 1999-10-05 2001-05-10 Ejasent Inc. Snapshot virtual-templating
US7210147B1 (en) 1999-10-05 2007-04-24 Veritas Operating Corporation IP virtualization
EP1903830A1 (fr) * 1999-11-01 2008-03-26 White. Cell, Inc. Procédé de sécurité de système de données cellulaires
WO2001033889A1 (fr) * 1999-11-01 2001-05-10 White. Cell, Inc. Procede et dispositif de securite pour systeme de donnees celullaires
DE10048113C2 (de) * 1999-12-04 2002-08-01 Nutzwerk Informationsgmbh Vorrichtungen und Verfahren zum individuellen Filtern von über ein Netzwerk übertragener Informationen
DE19958638C2 (de) * 1999-12-04 2002-05-23 Nutzwerk Informationsgmbh Vorrichtung und Verfahren zum individuellen Filtern von über ein Netzwerk übertragener Informationen
DE19961399C2 (de) * 1999-12-20 2002-08-22 Mueschenborn Hans Joachim Schutz sicherheitskritischer Daten in Netzwerken
US6496935B1 (en) * 2000-03-02 2002-12-17 Check Point Software Technologies Ltd System, device and method for rapid packet filtering and processing
US6981278B1 (en) 2000-09-05 2005-12-27 Sterling Commerce, Inc. System and method for secure dual channel communication through a firewall
US7596784B2 (en) 2000-09-12 2009-09-29 Symantec Operating Corporation Method system and apparatus for providing pay-per-use distributed computing resources
WO2002027503A1 (fr) * 2000-09-27 2002-04-04 Sony Corporation Systeme de reseau domestique
FI20010110A0 (fi) 2001-01-18 2001-01-18 Stonesoft Oy Pakettien lajittelu gateway-verkkoelementissä
FR2825214B1 (fr) * 2001-05-23 2003-10-31 Unlog Dispositif de communication electronique securise, notamment d'acces electronique securise
NO318091B1 (no) * 2002-03-04 2005-01-31 Telenor Asa System for bedret sikkerhet og bruker-fleksibilitet i lokale tradlose datanett
CN100339845C (zh) * 2002-08-15 2007-09-26 联想网御科技(北京)有限公司 基于状态检测的链路层统一资源定位符过滤的方法
FR2844415B1 (fr) 2002-09-05 2005-02-11 At & T Corp Systeme pare-feu pour interconnecter deux reseaux ip geres par deux entites administratives differentes
US9003048B2 (en) * 2003-04-01 2015-04-07 Microsoft Technology Licensing, Llc Network zones
WO2005067260A1 (fr) * 2003-12-31 2005-07-21 Applied Identity Procede et systeme pour deleguer l'acces a des ressources d'un reseau informatique
DE102005021854B4 (de) * 2005-05-11 2007-02-15 Siemens Ag Eigenschaften-basierte Zuweisung von Ressourcen zu Sicherheitsdomänen

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7143438B1 (en) * 1997-09-12 2006-11-28 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with multiple domain support

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9948261A2 *

Also Published As

Publication number Publication date
WO1999048261A9 (fr) 1999-12-16
WO1999048261A2 (fr) 1999-09-23
WO1999048261A3 (fr) 1999-11-04

Similar Documents

Publication Publication Date Title
US6182226B1 (en) System and method for controlling interactions between networks
US6453419B1 (en) System and method for implementing a security policy
US6178505B1 (en) Secure delivery of information in a network
Blaze et al. Trust management for IPsec
US9438577B2 (en) Query interface to policy server
US6408336B1 (en) Distributed administration of access to information
US7912856B2 (en) Adaptive encryption
US8935311B2 (en) Generalized policy server
US7272625B1 (en) Generalized policy server
US6219786B1 (en) Method and system for monitoring and controlling network access
CA2182777C (fr) Systeme de securite pour reseaux informatiques interconnectes
EP1062785A2 (fr) Systeme et procede reduisant les interactions entre reseaux
AU733109B2 (en) Methods and apparatus for controlling access to information
WO2000000879A2 (fr) Serveur de procedure generalisee
WO2000079434A1 (fr) Interface d'interrogation vers serveur de regles
Cisco Evolution of the Firewall Industry
Cisco Evolution of the Firewall Industry
Cisco Evolution of the Firewall Industry
Cisco Evolution of the Firewall Industry
Cisco Evolution of the Firewall Industry
Cisco Evolution of the Firewall Industry
AU762061B2 (en) Generalized policy server
Srinivasan Internet security agent for Windows NT using a layered service provider
Erdoğan Development of a distributed firewall administration tool
Maw Administrative domain security gateway for file transfer

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20001012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20030904

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MCAFEE, INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20131106