Ri

1. Request

4. Repackaged Response

2. Repackaged Request

3. Response

Web Server

• The proxy server requests connections between a client on the inside of the firewall and the Internet.

• Client requests are filtered on the basis of Layer 5 and Layer 7 information.

Client

4. Repackaged Response

Client

• The proxy server requests connections between a client on the inside of the firewall and the Internet.

• Client requests are filtered on the basis of Layer 5 and Layer 7 information.

By standing in the gap between the internal and external networks, application proxies separate the trusted and untrusted networks either physically or logically.

Figure 10-6 shows a client inside the network requesting access to a website. When the client attempts the connection, his browser uses a proxy server to fulfill all HTTP requests. Note that client-side DNS queries and client-side routing to the Internet are not needed when using a proxy server. All the client needs to be able to do is reach the proxy server to make the request.

Let's examine how the process works:

1. The proxy server receives the request from a client.

2. The proxy server performs user authentication according to the rules applied to it.

3. It uses its Internet connection to access the requested website. In accessing the website, it forwards only Layer 3 and Layer 4 packets that match the firewall rules.

4. When returning content to the requesting client, the proxy server forwards only Layer 5 and Layer 7 messages and content that the server allows (such as nonmalicious traffic) according to the firewall rules.

Application layer firewalls are designed for a single task—to provide the highest level of filtering for a specific protocol. Despite this benefit, a proxy server slows network performance because it must evaluate a significant amount of information embedded in a large number of packets.

Application Firewall Limitations

Application layer firewalls are very processor-intensive, requiring many CPU cycles and a lot of memory to process every packet that needs inspection. Sometimes this leads to issues with throughput. The detailed logging that they can provide, although beneficial, may also lead to significant consumption of disk space. Two solutions can address these issues:

■ Use a Context Transfer Protocol (CXTP)

■ Have the application layer firewall monitor only key applications

By using a CXTP, you can perform authentication and authorization exclusively, rather than adding the overhead of monitoring data on the connection. This greatly improves performance, although without monitoring, you are reducing your ability to be alerted to and track new attack types.

In the second solution, you limit the application layer firewall to processing only certain application types (such as e-mail, Telnet, FTP, or web services). To further reduce process usage, you could process only connections to specific internal resources. The downside of this approach is that you are not monitoring all applications and connections, and this creates a security weakness.

Another limitation of application layer firewalls is that because generally they do not support all applications, you cannot monitor data on all connections. Remember, generally they are limited to one or a small number of connection types, such as e-mail, Telnet, FTP, or web services.

Finally, some application layer firewalls require the installation of vendor-specific software on the client, which the firewall then uses to handle the authentication process and any connection redirection. This can greatly limit scalability and may create management problems if support for thousands of clients is required.

Static Packet-Filtering Firewalls

Packet-filtering firewalls, which typically are part of a router firewall solution, work by filtering traffic at the network layer of the OSI model (the IP layer of TCP/IP). Figure 10-7 shows how static packet-filtering firewalls map to the layers of the OSI model.

Figure 1G-7 Packet-Filtering Firewalls and the OSI Model

< Traffic is filtered based on specified rules. • Unknown traffic is only allowed to Layer 3

< Traffic is filtered based on specified rules. • Unknown traffic is only allowed to Layer 3

OSI Model

Application

Presentation

Session

Transport

Network

Data Link

Physical

Static packet-filtering firewalls act as Layer 3 devices and use filtering rules and ACLs to determine whether to permit or deny traffic based on source and destination IP addresses, as well as source and destination port numbers, and packet type. Rules may also be used to help these firewalls decide whether to reject any packet from the outside that claims to come from an address inside the network.

You will recall that each service relies on specific ports. Static packet-filtering firewalls can also control traffic flow based on ports. Therefore, by restricting certain ports, you can restrict the services that rely on those ports. For instance, if you wanted to block web traffic from a given host, you could block port 80, preventing the host from gaining access to websites.

Packet-filtering firewalls are similar to packet-filtering routers but offer additional benefits. For instance, packet filters are very scalable and application-independent and have high performance standards. The downside is that they do not offer the full range of security solutions required in today's networks.

Packet filtering may be performed by any device that uses ACLs. For instance, Cisco IOS router configurations frequently use ACLs, not only as packet-filtering firewalls, but also to select specified types of traffic to be analyzed, forwarded, or influenced in some way.

Figure 10-8 shows packet filtering using a Cisco router.

Figure 10-8 Static Packet Filtering Using a Cisco Router

ACL 101 applies to outgoing traffic.

192.168.C.X

ACL 102 applies to incoming traffic.

196.26.C.255

EO 192.168.C.1

196.26.C.255

EO 192.168.C.1

DNS Server 192.168.C.2

Mail Server 192.168.C.3

FTP Server 122.168.C.4

Other Servers 192.168.0.X

Other Servers 192.168.0.X

Specifications of the ACLs

• ACL 101- Allows All Outgoing TCP Connections

• ACL 102- Allows Incoming DNS, SMTP, and FTP Connections and Return Traffic

• ACL 102- Denies All Other Services

In most implementations, we seek to protect the Ethernet interface connecting to the internal (inside) network, while the serial interface that connects to the Internet (outside) is unprotected. In the example, our internal addresses that the firewall must protect are in the 192.168.0.x range (on the Ethernet interface). Our subnet mask is set to 255.255.255.0, making the IP address of the Ethernet 0 interface 192.168.0.1 255.255.255.0.

As you examine the network security policy shown in Figure 10-8, you see that ACL 101 allows all users from the inside to access Internet services on the outside. In this case, all outgoing connections are accepted. Our router, as configured, checks only packets coming from the Internet (security policy ACL 102).

As you can see, ACL 101 allows Domain Name System (DNS), mail, FTP services, and the return of traffic initiated from the inside, whereas ACL 102 denies access to all other services.

Stateful Packet-Filtering Firewalls

The most common firewall technology is stateful packet filters, or stateful firewalls. This is in no small part related to the fact that they are the most versatile firewall technology. The ability to dynamically filter packets is provided through stateful filtering. This stateful inspection is a firewall architecture that works at the network layer. Unlike static packet filtering, which examines a packet based on the information in its header, stateful inspection can track each connection traversing all interfaces of the firewall and confirm that they are valid.

Stateful Packet Filtering and the State Table

Stateful packet filtering maintains a state table that is part of the firewall's internal structure. It tracks all sessions and inspects all packets passing through the firewall. If a packet has properties matching those listed in the state table, the firewall allows the packet to pass. Depending on the traffic flow, the state table changes dynamically. Figure 10-9 shows how stateful packet filtering maps to the OSI model.

Figure 10-9 Stateful Packet Filtering and the OSI Model

Figure 10-9 Stateful Packet Filtering and the OSI Model

Stateful Inspection

OSI Model

Application

Presentation

Session

<s>

V

Transport

Network

Data Link

Physical

r

Stateful firewalls use the state table to keep track of the actual communication process. These firewalls operate at Layers 3, 4, and 5 of the OSI model. At the transport layer, the firewall examines information in the headers of Layer 3 packets and Layer 4 segments. The stateful firewall would examine the TCP header for SYN, RST, ACK, FIN, and other control codes to determine the state of the connection. In our example, the session layer is responsible for both establishing and tearing down the connection.

Whenever an outside service is accessed, the stateful packet filter firewall "remembers" certain details. In other words, it saves the details of the request in the state table. When a TCP or UDP connection is established, either inbound or outbound, the firewall logs the information in a stateful session flow table. This information is then used when the outside system responds to the request. The firewall compares the received packets with the saved state to allow or deny network access.

Source and destination addresses, port numbers, TCP sequencing information, and additional flags for each TCP or UDP connection associated with that particular session are contained in the stateful session flow table, or "state table." Together, this information creates a connection object. The firewall uses this connection object to compare all inbound and outbound packets against session flows in the stateful session flow table. The firewall permits data only if an appropriate connection exists to validate the passage of that data.

Features vary by firewall. Some of the more advanced stateful firewalls can parse FTP port commands to update the state table to allow FTP to work transparently through the firewall. To ensure that the only packets that are allowed back through the firewall are in response to queries that originate inside the network, TCP sequence number interpretation and DNS query and response matching are used. The threat of TCP RST flood attacks and DNS cache poisoning is greatly reduced through the use of these features.

Disadvantages of Stateful Filtering

Although stateful packet filtering offers speed and transparency, it has a potential disadvantage. Remember, packets must make their way to the outside network. In doing so, internal IP addresses might be exposed to potential hackers. To guard against this, most firewalls incorporate stateful inspection, NAT, and proxy servers together for added security.

To deal with this disadvantage, stateful firewalls keep track of the state of a connection and whether the connection is in an initiation, data transfer, or termination state. This information may be used when you want to deny the initiation of connections from external devices while still allowing users to establish connections to these devices and permit the responses to come back through the stateful firewall.

Figure 10-10 shows a successfully established HTTP TCP session. This session leads to a dynamic ACL rule entry on the outside interface and permits response packets from the web server to the client.

Figure 10-10 Stateful Firewall 75.1.1.1

Src Port 1500 -

Inside ACL (Incoming Traffic)

Outside ACL (Incoming Traffic)

permit ip 75.0.0.0 0.0.0.255 any

Dynamic:

permit tcp host 62.3.3.3 eq 80 host 75.1.1.1 eq 1500 permit esp any any permit udp any any eq 500 deny ip any any

Uses of Stateful Packet-Filtering Firewalls

Stateful packet-filtering firewalls may be used in a number of applications, as described in Table 10-4.

Table 10-4 Uses of Stateful Packet-Filtering Firewalls

Use of Firewall

Description

A primary means of defense

Stateful firewalls may be used as a primary means of defense by filtering unwanted, unnecessary, or undesirable network traffic.

An intelligent first line of defense

Routing devices that support a stateful function may be used as a primary line of defense or as an added layer of security on perimeter routers.

To strengthen packet filtering

Stateful filtering provides a cost-effective means to gain greater control over security than does packet filtering.

Improve routing performance

Stateful packet-filtering devices provide better performance than packet filters or proxy servers and do not require a large range of port numbers to allow returning traffic back into the network. By using the state table, the device can quickly determine whether a packet is returning traffic. If it is not, the filtering table filters the traffic.

Defend against spoofing and DoS attacks

Stateful packet-filtering firewalls track the state of the connection in the state table, listing every connection or connectionless transaction. Tracking whether packets belong to an existing connection or are from an unauthorized source lets these firewalls allow only traffic from connections listed in the table. After the connection is removed from the state table, the firewall does not allow any more traffic from that device. Stateful firewalls can log more information than a packet-filtering firewall can, allowing them to track when a connection was set up, how long it was up, and when it was torn down, making connections harder to spoof.

Stateful firewalls also have their limitations, as outlined in Table 10-5.

Table 10-5 Limitations of Stateful Packet-Filtering Firewalls

Stateful Firewall Limitation

Description

No prevention of application layer attacks

For example, a network might permit traffic to port 80 to a web server. A stateful firewall will examine the destination address in the Layer 3 packet and the destination port number in the segment. If a match occurs, the stateful firewall allows the incoming and outgoing traffic. The issue here is that the stateful firewall does not examine the actual contents of the HTTP connection, potentially allowing a malicious threat.

Not all protocols are stateful

Stateful firewalls cannot monitor protocols such as UDP and Internet Control Message Protocol (ICMP), which are not stateful.

Applications that open multiple connections

In an application such as FTP, if the client is inside the network and the server is outside the network, both stateful and packet-filtering firewalls have an issue dealing with the data connection that the FTP server establishes to the client. In this case a whole range of ports would need to be opened to allow this second connection.

User authentication is not supported

User authentication is not supported by stateful firewall technology when used alone.

Application Inspection Firewalls

Application inspection firewalls, sometimes called deep inspection firewalls, are used to provide for the security of applications and services. Of course, certain applications require special handling by the firewall application inspection function. Applications that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports require special application inspection functions.

Figure 10-11 shows an application layer firewall. Application inspection firewalls are essentially stateful firewalls with intrusion detection system capabilities. Specifically, application inspection firewalls

■ Are aware of the Layer 5 state of a connection.

■ Check the conformity of application commands on Layer 5.

■ Can check and affect Layer 7 (such as Java applet or peer-to-peer filtering).

■ Prevent more kinds of attacks than stateful firewalls.

Key Topic

Figure 10-11 Application Layer Firewall

An application inspection firewall operates on OSI Layers 3, 4, 5, and 7.

Layer 7

Application

Layer 6

Presentation

Layer 5

Session

Layer 4

Transport

Layer 3

Network

Layer 2

Data Link

Layer 1

Physical

The application inspection function uses NAT to help identify the location of embedded addressing information. NAT is used to translate embedded addresses and to update any checksum or other fields that are affected by the translation.

The application inspection function also actively monitors sessions to determine the port numbers for secondary channels. A number of protocols open secondary TCP or UDP ports. The initial session, which takes place on a well-known port, is then used to negotiate dynamically assigned port numbers. These sessions are monitored by the application inspection function. It can identify the dynamic port assignments, and it permits data exchange on these ports for the duration of the specific session. Let's see an example of how this is done.

We begin with an FTP client that opens a control channel between its port 2010 and the FTP server port 21. As data is to be exchanged, our FTP client alerts the FTP server through the control channel where it expects the data to be delivered. In this case it expects data from FTP server port 20 to its port 2012. If FTP inspection is not enabled, the return data from FTP server's port 20 to FTP client port 2010 is blocked by the stateful firewall. If FTP inspection is enabled, the stateful firewall inspects the FTP control channel to recognize that the data channel will be established to the new FTP client port 2012. Based on this, the firewall temporarily creates an opening for the data channel traffic for the life of the session.

An application inspection firewall behaves in different ways according to each layer, as described in Table 10-6.

Table 10-6 Inspection Firewall Behavior

OSI Layer

Behavior

Transport layer

With the transport layer, the application inspection firewall acts like a stateful firewall by examining information in the headers of Layer 3 packets and Layer 4 segments. The application inspection firewall looks at the TCP header for SYN, RST, ACK, FIN, and other control codes to determine the state of the connection, for example.

Session layer

With the session layer, the application inspection firewall checks the conformity of commands within a known protocol. For example, when it checks Simple Mail Transfer Protocol (SMTP), only acceptable message types on Layer 5 are allowed (DATA, HELO, MAIL, NOOP, QUIT, RCPT, RSET). It also checks whether the command attributes that are used conform to the internal rules.

Application layer

With the application layer, the application inspection firewall protocol is rarely supported. Application layer firewalls may provide protocol support for HTTP, and they can determine whether the content is really an HTML website or a tunneled application. If it were a tunneled application, the application inspection firewall would block the content or terminate the connection.

Application inspection firewalls also offer a number of advantages:

■ Application inspection firewalls are aware of the state of Layer 4 and Layer 5 connections. For example, they know that a Layer 5 SMTP mail-from command always follows a HELO command.

■ Application inspection firewalls check the conformity of application commands on Layer 5.

■ Application inspection firewalls can check and affect Layer 7, as previously discussed.

■ Application inspection firewalls can prevent more kinds of attacks than stateful firewalls.

Application Inspection Firewall Operation

Figure 10-12 shows inspection engines, a subset of the application inspection firewall. As you can see, one inspection engine is responsible for checking a specific protocol.

Figure 10-12 Application Inspection Firewall Operation

Inspection Engines:

• Protocol Support Through Firewalls

• Conformity of Commands Through Checks

Java

<

Java

<

Pre-FSIP Server 62.3.3.3

Web Server 62.3.3.4

Web Server 62.3.3.4

Inspect Outgoing Traffic

Inspect Incoming Traffic

Session Initiation Protocol To: INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=4c101d Media Port: 33005

Source

Destination

Protocol

Action

62.3.3.3

75.1.1.1

TCP 5060

Permit

Source

Destination

Protocol

Action

62.3.3.3

75.1.1.1

UDP 33005

GET/HTTP/1.1\r\n Host: www.magazin.com\r\n

Filtered Java Applet

<applet code="fbun.class" width=550 height=300

align="left">

</applet>

The first example shows how a client establishes a pre-Fast Serial Interface Processor (pre-FSIP) session to the pre-FSIP server and then a voice call controlled by pre-FSIP. You can see that the application inspection firewall dynamically inspects and allows response traffic from the pre-FSIP server. In addition, the Layer 5 traffic is being inspected, and the pre-FSIP inspection engine recognizes a pre-FSIP call setup by understanding the pre-FSIP protocol INVITE message on this layer. Notice that the inspection engine dynamically reads the used media port for the Real-time Transport Protocol (RTP) data stream and dynamically allows that traffic to pass through the firewall.

The next example shows a user opening a website on a web server. The HTTP inspection engine recognizes on Layer 7 that the site contains a Java applet and filters the applet because of filtering rules.

Effective Use of an Application Inspection Firewall

Although application inspection firewalls have their place, they are not without disadvantages:

■ Only a few inspection engines currently are available that support Layer 7 content because it is so complex.

■ Alone, application inspection firewall technology does not support user authentication.

■ An extra load is placed on the firewall's processing capacity as the application inspection firewall is busy building and maintaining the state table. As monitored connections increase, the more processing power your application inspection firewall needs to maintain the table, driving up operation cost.

Application inspection firewalls are appropriate for specific situations. Table 10-7 describes these possible scenarios.

— Table 10-7 Uses of an Application Inspection Firewall

— Table 10-7 Uses of an Application Inspection Firewall

Use of Firewall

Description

Secondary means of defense

By filtering unwanted, malicious, or undesirable traffic, an application inspection firewall is used as a secondary means of defense.

To provide more stringent controls over security than stateful filtering provides

Without adding significant cost, application inspection firewalls provide a more stringent means of examining traffic compared to a stateful firewall. They also provide more control than stateful filtering firewalls do, at a minimal increase in cost.

Overview of the Cisco ASA Adaptive Security Appliance

The Cisco ASA 5500 Series Adaptive Security Appliance can scale to meet a range of requirements and network sizes. Currently the ASA 5500 Security Appliance family has six models: the ASA 5505, 5510, 5520, 5540, 5550, and 5580. This section explores the Cisco ASA adaptive security appliance and its role in securing the network. Figure 10-13 shows these various ASA appliances and their roles in meeting business needs.

The ASA 5505 has a number of features, including a built-in Layer 2 switch with eight Fast Ethernet ports that can be divided into VLANs. The ASA 5510, another in the family, can support three integrated Fast Ethernet ports as well as one out-of-band management port. If you have an upgrade license, the ASA 5510 can support five Fast Ethernet ports. Other members of the product line support a single management 10/100 Fast Ethernet port and four Gigabit Ethernet ports (ASA 5520 and 5540). The ASA 5550 supports a single management 10/100 Fast Ethernet port and 12 Gigabit Ethernet ports. Of these, only eight can be used at any given time. Four of these can be used for copper Gigabit Ethernet termination only; the other four may be used for either copper or fiber Gigabit Ethernet termination. The ASA 5580-20 and 5580-40 round out the Cisco ASA family of products. These systems provide service provider level capabilities, including 1-Gbps VPN throughput, the ability to support up to 10,000 concurrent SSL or IPsec VPN sessions, and a 4-RU profile, stateful failover, and VPN load balancing. These 5580 ASAs also offer the largest number of interfaces with two USB ports, two RJ-45 management ports, and two gigabit Ethernet management ports.

Figure 10-13 Cisco ASA 5500 Series Adaptive Security Appliance Family

ASA 5500 Series

ASA 55G5

ASA 55G5

ROBO SMB

ASA 555G/558G

ASA 554G

ASA 552G

ASA 554G

ASA 552G

ASA 555G/558G

ASA 551G

ASA 551G

ROBO SMB

Enterprise Service Provider

Functionality

Secure Socket Layer (SSL) VPNs are also supported by the ASA 5500 family of products. An optional Security Services Module (SSM) also is supported on selected units (ASA 5510, 5520, 5540). Even without these added features, the Adaptive Security Appliance is secure right out of the box. With only a few installation procedures and a brief initial configuration, the ASA is operational and can begin protecting your network.

The Role of Firewalls in a Layered Defense Strategy

Firewalls provide perimeter security for the entire network and for internal network segments in the core in a layered defense strategy. Firewalls can be used to separate an organization's human resources or sales networks from other networks or network segments within the organization, adding a layer of security. Figure 10-14 explores the role of firewalls in the layered defense strategy.

Figure 10-14 Role of Firewalls in the Layered Defense Strategy

Figure 10-14 Role of Firewalls in the Layered Defense Strategy

A layered defense strategy employs multiple firewalls of varying types, combined in layers to add depth to an organization's information defenses. Let's examine how this might work.

We will begin with traffic coming from the untrusted network. In a layered defense, the traffic first encounters a packet filter on the outer router. Next, the traffic goes to either a screened host firewall or a bastion host system. This system applies more rules to the traffic and discards any suspect packets. If the traffic is not discarded, it goes to an interior screening router. Only after this series of steps does the traffic pass to the internal host that is the destination. This multilayer approach is called a demilitarized zone (DMZ) or a screened subnet configuration.

Even with the benefits of a layered firewall topology, you cannot implement this and then declare your internal network to be safe. Although some firewall manufacturers may encourage this mentality, you still need to consider a number of factors to build a complete defense in depth:

..— ■ Firewalls do not protect you from the significant number of intrusions that come from

\ Topic hosts within the network. One example of this is that firewalls do little to protect against viruses downloaded through e-mail.

■ Firewalls cannot protect against rogue modem installations.

■ Firewalls are not a substitute for well-planned backup and disaster recovery mechanisms that may need to be implemented because of attack or hardware failure. An in-depth defense helps in these situations by implementing offsite storage and redundant hardware topologies.

Creating an Effective Firewall Policy

Some organizations are quick to put technology in place without first taking the time to develop a sound security policy. Remember, the firewall(s) that you implement should be in accordance with your policies. Your policies should not be solely driven by your technologies. Having said this, your firewall policy should be developed before you approach implementation. It should detail what traffic the firewall will filter and the nature of network connectivity needed before you begin any implementation efforts.

If you don't take the time to develop a well-thought-out firewall policy, one that takes into account your business needs, you can end up making what seem to be good decisions, only to find out that you have impaired your organization's ability to conduct business. For example, suppose you have configured your firewall to block Microsoft Remote Procedure Call (RPC)-based traffic from entering or leaving a protected subnet. On the surface this might seem like a good idea. However, later you learn that users in that subnet need RPC services to contact hosts on the outside. If you have not defined appropriate RPC filtering rules, it will be difficult to deny access to these workers, particularly if this means that you will impair their productivity or, worse, cause them to be unable to work at all. Decisions like this, made without a full understanding of the impact, often cause administrators to have to make an exception. After one exception is made, more exceptions are likely to come into practice, leading to the construction of filtering rules that are complex and ultimately unmanageable.

Always be mindful that your filtering and connectivity policies incorporate a clear understanding of the organization's security and business needs. In the example just discussed, a better solution would be to locate the firewall at the Internet gateway, rather than at the subnet. This would give users the RPC access they need without compromising overall security. Most situations can be handled with careful planning and a solid understanding of your business needs.

Cisco offers a number of best-practice lists to guide you in developing a sound firewall policy. Table 10-8 summarizes a number of key points to add to what we have discussed so far.

Table 1G-8 Best Practices When Developing a Firewall Policy

Best Practice

Description

Trust no one

It is best to deny all traffic by default and enable only those services absolutely necessary to conduct business. Understand what information users need, and give them access to only that information. Employ the least-privilege principle to grant no more privilege than is necessary for a user to perform his or her job successfully.

When configuring the firewall, eliminate unneeded or redundant rules to ensure that your configuration supports your specific needs.

Deny physical access to firewall devices

Be sure that physical access to the firewall is controlled.

Allow only necessary protocols

Develop a list of the protocols you need to support to allow business operations to connect to other networks and subnetworks, and allow only these necessary protocols. For instance, you might want to disable protocol inspection for traffic types that are not on your network.

Use logs and alerts

Develop a logging strategy that takes into account the level and type of logging needed, and be sure to monitor logs on all firewalls regularly. To make log modifications and manipulation difficult for an attacker, use a secure remote syslog server.

Segment security zones

Firewalls can be used to protect internal systems from internal misuse as well as their traditional role of protecting public servers from being accessed by malicious attacks from the Internet. Firewalls can be used to create DMZs to limit access to defined security zones within your organization.

Do not use a firewall as a server

Firewalls should never be included in server consolidation plans. You should, however, disable or uninstall any unnecessary services and software on the firewall. Also, be sure to remove management tools from firewalls to prevent hackers from installing Trojan horse software or back doors. Programs such as antivirus, content filtering, VPN, DHCP, and authentication software should be run on other dedicated systems behind the firewall.

Never use a firewall as a workstation for a user

Workstations rely on a variety of client applications (Microsoft Internet Explorer, Microsoft Outlook Express, FTP, and so on) that can expose a firewall to viruses, worms, and other exploits.

Set connection limits

Enforcing connection limits on Cisco security appliance firewalls can mitigate worms and other automated attacks. Default connection limits can be changed in the global settings.

Table 10-8 Best Practices When Developing a Firewall Policy (Continued)

Best Practice

Description

Restrict access to firewalls

Firewall accounts should be restricted to administrator use. No network logins should be allowed. Use strong passwords or challenge-response and OTP cards. A unique user ID should be used instead of "administrator" or "root." Each firewall should have a different user ID and password.

Combine firewall technology

Packet filtering alone should not be your sole line of defense. Combine this with stateful inspection, protocol inspection, and application inspection, as applicable.

Use firewalls as part of a comprehensive security solution

Firewalls should be used in conjunction with other devices to build a full security solution. They should be integrated with other technologies, including these possibilities:

• Network intrusion detection system (IDS) and IPS

• Personal firewalls

• Antivirus software

• E-mail and web content filtering software

• URL filtering software

• Third-party authentication systems

Maintain your installation

Software patches and updates should be kept current. Be sure to perform system maintenance in a regular and timely fashion. Take care to patch your network operating system and application software with the latest code on a regular basis. Be sure to test these updates in a controlled, nonproduction environment whenever possible before application. Update your firewall configuration as application requirements change.

0 0

Post a comment