Internet Access Module


The Internet module houses the devices that provide Internet connectivity to the organization. The Internet module is essentially a hub of connectivity, providing access between the following modules:

  • Internal network and the Internet

  • VPN/remote access module and the Internet

  • Extranet module and the Internet

  • E-commerce module and the Internet

Figure 11-5 depicts a fully redundant Internet module. The first component of your Internet module is the use of redundant routers connecting to separate ISPs using Border Gateway Protocol (BGP) for Internet routing. The routers connect to separate switches and use Hot Standby Router Protocol (HSRP) to advertise a virtual router as the gateway. In addition, you should implement the first layer of filtering on these routers. You should implement an IDS/IPS at the switch to interrogate all traffic coming from the Internet to the firewalls. The firewalls are configured with two DMZs on a stick. One DMZ provides access to public services such as SMTP, DNS, FTP, and HTTP. The other DMZ provides content filtering functionality for the firewalls to ensure that no unauthorized or objectionable content is permitted to or from the internal network. Both DMZs follow the redundant design implementing dual switches with an IDS/IPS implemented on the public services DMZ to interrogate all traffic sent to and from the DMZ. Finally, the firewalls connect to the internal network, again implementing an IDS/IPS to interrogate all traffic sent to and from the internal network.

click to expand
Figure 11-5: Redundant Internet module

Traffic Flow Through the Internet Module

In a properly implemented Internet module, the only traffic that actually passes between the internal network and the Internet are the web requests that are sourced from the internal network and must be permitted by the content-filtering server and firewall. All other traffic uses proxies in a DMZ for connectivity. Figure 11-6 depicts the traffic flow using this system. For example, SMTP e-mail from the Internet goes to an SMTP server on the DMZ, which then forwards the e-mail to the internal network. By ensuring that all traffic that enters the internal network must go through a proxy or must be a response to an outbound Internet request, you protect your internal network from external threats. You should never allow traffic to be initiated inbound directly from the Internet.

click to expand
Figure 11-6: Traffic flow between the internal network and the Internet

Firewall Implementation

The heart of the Internet module is the firewall system. The firewall system consists of the routers, switches, firewalls, and IDS at the core of the Internet module. I refer to this as a firewall system because I believe that the concept of a standalone firewall providing security is a flawed design. Security is achieved in layers, and the firewall system uses layers at the external routers, the IDSs, and finally the firewalls themselves to provide perimeter security.

External Router Configuration

Your external router is the first line of defense in your firewall system, and consequently it is at your external router that you should implement basic spoof mitigation and filtering of traffic that is entering your network. The following task list details the hardening steps to undertake on your external router:

  • Implement RFC1918 (Private Address Space), RFC2827 (Network Ingress Filtering), and bogon Filtering (filtering unassigned address spaces).

  • Drop fragmented traffic.

  • Implement Authentication, Authorization, and Accounting (AAA).

  • Implement management console access restrictions using AAA and ACLs.

  • Harden the routing protocols.

  • Implement ACLs to restrict SNMP access.

  • Implement flood management through the use of traffic shaping, Quality of Service (QoS), and Weighted Fair Queuing (WFQ) on routers that support it.

  • Remove all unnecessary services.

  • Implement logging with syslog, SNMP traps, and accounting.

  • Drop directed broadcasts.

  • Implement anti-spoofing . Don t allow your internal IP range to be the source address of packets arriving on the external interface.

  • Prevent source routing.

  • Prevent ICMP redirects.

  • For your Cisco routers, implement Cisco Express Forwarding (CEF) to handle SYN floods.

  • Ensure that you are running the latest stable software version to prevent being susceptible to threats that have been patched or updated.

  • If your router has the horsepower to support it, implement the first line of traffic filtering to allow only traffic that should be traversing the network edge through the use of ACLs, or in the case of Cisco routers running the IOS firewall feature set and using Context Based Access Control (CBAC).

IDS/IPS Configuration

The IDS/IPS configuration depends largely on where in the module the IDS/IPS is implemented. For the IDS/IPS located at the public edge, you should implement a more broad analysis. This is because at this point any alarms do not represent an actual breech of the network; rather, they merely represent potential attempts.

As you get closer to the internal network, you need your IDS/IPS to take a more focused approach to traffic analysis. For example, on the public services DMZ, you know exactly what traffic is permitted, allowing you to focus the alarms for the network-based IDS/IPS (NIDS/NIPS) on traffic matching those patterns. In addition, you need to implement host-based IDS/IPS (HIDS/HIPS) on the servers in the DMZ to protect against operating system “level tampering.

The IDS/IPS implemented between the firewall and the internal network is where you need to undertake the most stringent analysis. This is because any suspicious traffic that has been able to make it this far is inside your perimeter defenses. Very few attacks should be detected at this point, and every attack detected should be treated with the utmost of importance.

Firewall Configuration

The actual firewalls are the core of your firewall system. The firewalls are ultimately responsible for filtering permitted traffic to the specific hosts while ensuring that nonpermitted traffic is blocked accordingly . This is typically done through the use of ingress and egress filtering.

Implementing Ingress Filtering Ingress filtering is the traditional method of filtering traffic to your network resources that is sourced from the Internet. For Cisco PIX firewalls and IOS-based network equipment, ingress filtering is implemented through the use of ACLs. For Check Point firewalls, ingress filtering is implemented as part of the ruleset with the appropriate source (Internet) and destination (DMZ) addresses.

An example of implementing ingress filtering with a Cisco PIX firewall uses the following steps:

  1. Implement an ACL.

  2. Implement a static mapping or internal and external resources.

  3. Apply the ACL to an interface.

Implementing an ACL is a straightforward process. You can run the following commands at the global configuration mode to implement an ACL for basic Internet functionality:

 access-list 100 permit tcp any host 1.1.1.10 eq www  access-list 100 permit tcp any host 1.1.1.10 eq ftp  access-list 100 permit udp any host 1.1.1.11 eq domain log access-list 100 permit tcp any host 1.1.1.12 eq smtp 

In this example, you are permitting any traffic to access the web server and FTP server on IP address 1.1.1.10, the DNS server at 1.1.1.11, and the SMTP server at 1.1.1.12. If you wanted to log all traffic that matches these entries, you could add the syntax log at the end of the ACL, as shown in the third line. This would cause the connections that match the traffic to be logged via syslog. These four services are the most commonly implemented services that Internet-based hosts need to access and in many cases are the minimum required ingress filters that most companies need.

The next step is to implement a static mapping that correlates the external address to the internal address of the server that provides the services that are being used. There are two schools of thought about how to implement the static mappings. The first is simply to create a static mapping from one IP address to the other IP address. The problem with this implementation is that if someone misconfigures an ACL, the traffic would be able to access the protected resource since the static mapping already permits all traffic. The other school of thought is to configure the static mapping to support only the explicit traffic that you want to map. This is the configuration that I recommend, since to cause a security breach, it would take someone misconfiguring not only the ACL but the static mapping as well. The following example is an illustration of static mappings that map the explicit ports and services to correspond with the ACL from the previous example.

 static (DMZ01,outside) tcp 1.1.1.10 www 192.168.1.10 www netmask  255.255.255.255 0 0  static (DMZ01,outside) tcp 1.1.1.10 ftp 192.168.1.10 ftp netmask  255.255.255.255 0 0  static (DMZ01,outside) udp 1.1.1.11 domain 192.168.1.11 domain netmask  255.255.255.255 0 0  static (DMZ01,outside) tcp 1.1.1.12 smtp 192.168.1.12 smtp netmask  255.255.255.255 0 0 

The final step is to apply the ACL to an interface using the access- group command. The following example illustrates how to apply the ACL to the outside interface for all inbound traffic:

 access-group 100 in interface outside 

Implementing Egress Filtering Egress filtering is the filtering of traffic that is sourced from protected networks such as DMZ segments or the internal network to external resources. Egress filtering is often overlooked because folks inadvertently focus on controlling what is entering their network, not what is exiting their network.

Part of what probably contributes to the lack of use of egress filtering is a little bit of confusion as to how egress filtering functions in regard to a stateful firewall. For example, if I implement a firewall with ingress filtering as previously described and then implement egress filtering that blocks all traffic from the DMZ segment, many folks believe that will prevent the servers on the DMZ from being able to respond to external requests. However, this is not correct. Remember that the whole point of being a stateful firewall is its ability to remember the state of all conversations so that valid responses can be passed through the firewall accordingly. So the servers would still be able to respond to all external requests; however, they could not originate any packets through the DMZ interface. This is particularly valuable in ensuring that hosts on the DMZ cannot pass traffic back to the Internet in the event that they are compromised.

The following code example illustrates how to implement an egress filter that permits only SMTP and DNS traffic that is sourced from the servers on the DMZ in the previous example. This allows you to use the DNS server in your DMZ as a DNS forwarder for your internal hosts as well as the SMTP server as the SMTP relay for both incoming and outgoing e-mail, while preventing all other traffic that is sourced from the DMZ servers from being passed by the firewall:

 access-list 200 permit tcp host 192.168.1.12 any eq smtp  access-list 200 permit udp host 192.168.1.11 any eq domain  access-list 200 deny ip any any log static (inside,DMZ01) tcp 192.168.1.12 smtp 172.16.1.12 smtp netmask  255.255.255.255 0 0  access-group 200 in interface DMZ01 

No good baseline is available for implementing egress filtering since the traffic that should be permitted to exit the network largely depends on the resources that are located on that network segment. The best approach is to allow the absolute minimum traffic required.

Content-Filtering Configuration

The content-filtering DMZ should be restricted by egress filtering to permit only the content-filtering traffic between the content-filtering server and the firewall. All other traffic is unnecessary and potentially unsafe. In addition to filtering the traffic at the firewall, you should implement an HIDS/HIPS to alarm and prevent any attacks that might traverse the firewall.




Hardening Network Infrastructure. Bulletproof Your Systems Before You Are Hacked.
Hardening Network Infrastructure. Bulletproof Your Systems Before You Are Hacked.
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net