The extranet access module is almost a hybrid of the Internet access module in the sense that this module exists primarily to allow external hosts to access services and resources in your network. The difference lies in to whom that access is granted. For the Internet access module, virtually anyone on the Internet is allowed to access the public services that you make available. For the extranet access module, the only systems that can access the resources are the external partners to which you explicitly grant access. All other hosts will be denied access.
This is accomplished by placing the application servers that are required in a DMZ using the firewalls on the external edge to control access to the servers for external hosts and placing firewalls on the internal edge to restrict further access to the internal network. A variation on this design also uses VPN connectivity to terminate the external partner connections securely. The systems in the application server DMZ should contain all of the information required by your extranet partners, or they should be configured as proxies to access information from the internal network (for example, data that resides on a mainframe or in a database server) on behalf of the extranet partner. Like the Internet access module, no traffic should be able to pass from the external network to the internal network without going through a proxy. This design is illustrated in Figure 11-9.
As is customary for all of our perimeter modules, NIDS/NIPS are deployed on the application services DMZ to analyze and monitor traffic to ensure that no unauthorized traffic is being passed. In addition, the servers should each be running an HIDS/HIPS to protect the server against operating system “level tampering. Finally, an NIDS/NIPS is deployed behind the internal firewall to monitor and analyze the traffic traversing the module to the internal network.