JUNOSe 9.1.x IP Services Configuration Guide > Configuring Firewall > Overview

Overview

Firewalls control access to your network to protect it from costly misuse and malicious intent from other users (for example, denial-of-service [DoS] attacks). You position firewalls at all of your network entrance points to provide effective network access control.

You typically place firewalls between an internal network (or your computer, the "trusted" network) and the external network (like the Internet, an "untrusted" network). This placement forces all incoming traffic from the external network to pass through your firewall before it enters your network. In order to safely communicate outside your own network, you must set up rules of communication and provide failsafes between your network and the outside world.

Depending on your needs, you may require a simple or an elaborate firewall. The following sections discuss some of the typical methods of access control, the sorts of issues they protect against, and how you can configure them within your network.

Denial-of-Service Attacks

Denial-of-service (DoS) attacks attempt to deny valid users access to network or server resources by using up all the resources of the network element or server. By using up all the resources, a malicious user can deny access by valid users.

There are many kinds of DoS attacks. Some can be thwarted by using stateless filtering, while others may require state (flow) information. The following list describes some common DoS attacks:

• Synchronization (SYN) flood—Attempting to create a large number of Transmission Control Protocol (TCP) connections by sending synchronization packets but not completing the connections. Known as half-open connections, these incomplete SYN packets take some time to be removed. Because servers often have a limit on the number of connections allowed, this type of attack denies service to valid users.
• Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP) flood—Preventing access to a network or host with a flood of either UDP or ICMP packets above that which the network elements can handle.
• Ping of death—Sending very large and fragmented ICMP packets that may cause some IP stacks to crash.
• Land attack—Sending TCP SYN packets with the source and destination address set to the address of the machine being attacked.
• Teardrop—Sending the first and second part of a TCP packet in different IP fragments with overlapping offsets, causing the target host to crash.
• IP source route attack—Using the source route option, an attacker can masquerade as a trusted host.
• IP multicast source—Using a multicast source to cause a response that consumes network resources.
• TCP state machine attacks—Setting both the SYN and finish (FIN) bits or the FIN bit with no acknowledgment (ACK) bit within TCP packets.
• Other UDP issues—Sending a UDP echo to IP broadcast destination addresses (called a fraggle attack) consumes network resources (because all hosts on the subnetwork respond). Sending a UDP packet in which the UDP length is less than the IP length can cause some systems to crash.

About Stateless Access Control

You can address certain firewall issues (for example, address spoofing) by using stateless access control. In stateless access control, you can use the E-series policy manager to provide solutions. (See Chapter 1, Configuring Routing Policy.)

The E-series routers automatically provide some stateless checks as part of their normal forwarding feature set:

• IP datagram length check
• IP fragment offset
• IP checksum check
• IP address spoofing check
• Land attack check
• Broadcast or multicast source address check
• Illegal or reserved source or destination address check

Of these checks, some occur by default in the forwarding path (like checking the IP checksum) and you can explicitly configure others (like checking for illegal or reserved addresses using source address validation).

You can use policies to deny access to various packets (for example, ICMP packets or packets with certain options). Some policy examples include:

• Allowing or disallowing certain applications based on transport address (port)
• Disallowing packets with well-known IP, TCP, or UDP signatures
• Allowing or disallowing certain IP protocols (TCP, UDP, ICMP, and so on)

Understanding Stateful Access Control

After you configure a firewall for a protocol, all packets that belong to those applications which, in turn, use that protocol are subject to stateful monitoring. Stateful access control guards a network by allowing traffic only in the trusted direction. By inspecting the traffic, the firewall allows access to a restricted set of traffic. This process is called poking a hole in the firewall.

You can configure stateful access control on a per-interface basis. In addition, you can configure the firewall to inspect traffic on either the ingress or egress side of the interface. This configuration allows you to create a firewall at any interface and also choose which side of that interface is considered trusted or untrusted.

With state-based access, you can filter basic TCP, UDP, and ICMP flows, as well as handle certain applications that use in-band signaling to establish new flows (that is, they use a control connection to set up and tear down secondary connections to your network).

Basic support for the stateful firewall includes TCP, UDP, and ICMP flows. Application-specific support, which takes precedence over basic support, is available for some simple connection applications (for example, DNS, HTTP, HTTPS, POP-2, POP-3, RTSP, SMTP, SSH, TCP, TELNET, UDP, and ICMP) and for FTP (a more complex connection application). This support provides the ability to permit only specific applications while denying others.

NOTE: Application-specific support also allows for application-specific idle timeouts.

TCP Support

To support TCP connections, the JUNOSe stateful firewall supports the following:

• Ability to recognize the start of a new connection using a new 5-tuple on the trusted side of a firewall.
• Ability to add the new connection to the flow table and recognize the return flow.
• Timing out of a connection if the three-way SYN handshake is not completed, or if the connection idle time exceeds the specified timeout value.
• Monitoring the number of half-open TCP connections from a host for SYN floods, and blocking the offending host if the number of half-open TCP connections exceeds the configured threshold.
  

  NOTE: This kind of support is equivalent to passive SYN flood protection; the router does not actively reset the connection.

  
  
• Removal of connections that have been idle for a configured length of time.
• Verification of TCP flags on a packet-by-packet basis.
• Monitoring of TCP sequence and ACK numbers for out-of-range packets.

UDP Support

To support UDP flows, the JUNOSe stateful firewall supports the following:

• Ability to recognize the start of a new flow using a new 5-tuple on the trusted side of a firewall.
• Ability to add the new flow to the flow table and recognize the return flow.
• Monitoring the flow for the last access time (for timeout purposes).
• Monitoring the number of unidirectional flows from a host and blocking the offending host if the flows exceed the configured threshold.
• Removal of flows that have been idle for a configured length of time.
• Verification of the UDP length with respect to the IP length.

ICMP Support

When ICMP flows are enabled, the JUNOSe stateful firewall supports flows from trusted networks for echo request and timestamp request messages. Responses to these flows are allowed when the outgoing request is matched based on the source, destination, protocol, and session ID. Also, when related to an established connection, the ICMP firewall support allows ICMP error messages (that is, ICMP destination-unreachable and time-exceeded messages) to pass through. All other ICMP request types are blocked.

Inspection List and Half-Open Connection Support

Firewalls must apply rules to determine whether or not a connection is allowed. You determine these rules by configuring inspection lists and half-open table parameters. When a user configures an interface to have an inspection list, that list (or lists, when you configure both an ingress and egress list) controls the types of traffic (for example, protocols or ports) that are allowed to traverse the firewall.

Attaching an inspection list to the ingress channel of an interface establishes traffic received on that interface as trusted. That is, the interface allows traffic flows that receives on the interface to pass through the firewall. Attaching an inspection list to the egress channel of an interface establishes traffic routed to the interface as trusted. That is, the interface allows internally routed traffic flows to pass through the firewall.

In addition, the firewall also uses the half-open table to monitor connections. The half-open table allows for DoS mitigation, by limiting the number of half-open connections at any given time.

Application-Level Inspection Support

Firewalls may need application-level gateway (ALG) support for the following reasons:

• When using Network Address Translation (NAT) in conjunction with a firewall, the application may include information in the data stream that includes IP addresses or TCP/UDP ports. Because NAT changes the addressing information in the header of a packet, for the application to function properly, the data stream must be adjusted accordingly. For firewall configurations that do not include NAT, this adjustment is not an issue.
• The application may consider multiple TCP/UDP connections to be part of a single session. In this instance, a host outside the trusted network may initiate one or more of the connections based on signaling data from the host on the trusted network and, as a result, would be denied passage by the firewall. A classic example of this is the use of FTP, in which the server actually creates the data connection. The firewall must inspect the control connection to allow the incoming data connection.
• The application may suffer from some application-level attacks that may trigger the firewall to protect the network. In this case, the firewall must inspect the data stream, and modify it, to avert the attack. An example of this is an FTP man-in-the-middle attack, in which a third host (not part of the initial client server connection) is specified as the recipient of the data stream. The JUNOSe firewall prevents third-party transfers.
  

  NOTE: This release supports only ALGs for FTP.

  
  

The stateful firewall allows the ALGs to install new flows as needed for the application to function correctly.

Audit Trails

Because firewalls typically reside at the edge of a network, they can provide useful information about the use of network resources. As a result, firewalls can provide audit information.

NOTE: JUNOSe software can provide audit information, when configured, by using the flowServicesFirewallAudit log.

Safe IP Fragmentation

IP fragments can be used to perpetrate several types of attacks on a network (for example, the teardrop attack). Unfortunately, turning off IP fragmentation is not always an option. To ward against attacks that use fragmentation, the JUNOSe stateful firewall supports virtual reassembly for TCP and UDP packets, as well as reassembly and forwarding of ICMP packets.

With virtual reassembly, the router keeps a state entry for each set of fragments (datagram; initial fragments create an entry in the state table). The router verifies other fragments to be correct (based on state table information) and forwards them. In addition, the initial fragment must include the complete TCP or UDP header to mitigate the tiny fragment attack. The router times out any remaining state entries that exist for any incomplete fragments (datagram).

Because some networks may cause reordering of fragments (initial fragments may not be received first), and result in the virtual reassembly feature dropping fragments, this solution may not be ideal for all networks.

For ICMP reassembly and forwarding, the router buffers all fragments, reassembles them, and forwards only complete and correct packets.

DMZ Support

The DMZ (demilitarized zone), sometimes referred to as the service network, is a firewall concept in which a small, physically separated section of the trusted network is used to host connections from the untrusted network. An example is a Web server for a company on which incoming connections are allowed.

The need to provide access means that the network may be subject to external DoS attacks. The JUNOSe stateful firewall can provide protection against these attacks.

You can protect the DMZ in several ways, including the following:

• Using a normal policy list that you configure to allow access to only certain services.
• Defining rate limits at the physical interface.
• Configuring the JUNOSe stateful firewall to provide DoS protections (for example, against SYN flood).

Using a DMZ does not exclude the ability to use firewall functionality elsewhere in your network. By using a combination of ingress and egress firewall configurations, you can create a DMZ and have specific servers, containing specific applications, behind the firewall.