ProCurve Secure Router OS Firewall Protecting the Internal, Trusted Network

4 ProCurve Secure Router OS Firewall Protecting the Internal, Trusted Network Contents Overview...................................................... 4-3 Advantages of an Integrated Firewall........................... 4-3 Stateful-Inspection Firewalls.................................. 4-4 Packet-Filtering Firewall.................................. 4-4 Circuit-level Gateway.................................... 4-6 Application-level Gateway................................ 4-7 Attack Checking............................................ 4-9 SYN-flood Attacks...................................... 4-10 WinNuke Attacks....................................... 4-11 Reflexive Traffic........................................ 4-12 Event Logging............................................. 4-12 Configuring Attack Checking.................................... 4-14 Enabling the Secure Router OS Firewall....................... 4-14 Enabling and Disabling Optional Attack Checks................ 4-15 Checking Reflexive Traffic................................... 4-16 Configuring Stealth Mode.................................... 4-17 Configuring ALGs.............................................. 4-18 Enabling the FTP ALG...................................... 4-19 Enabling the H.323 ALG for Voice and Videoconferencing........ 4-19 Enabling the SIP ALG for Voice over IP........................ 4-19 Enabling the PPTP ALG for VPNs............................. 4-20 Enabling Firewall Traversal.................................. 4-20 Configuring Timeouts for Sessions............................... 4-21 Setting the Timeout for a Protocol............................ 4-21 Setting Timeouts for Specific TCP and UDP Applications........ 4-22 4-1

Contents Configuring Logging............................................ 4-24 Specifying the Priority Level for Logged Events................. 4-24 Specifying How Many Attacks Generate a Log.................. 4-26 Specifying How Many Policy Matches Generate a Log........... 4-27 Forwarding Logs to a Syslog Server........................... 4-27 Forwarding Logs to an Email Address......................... 4-29 Quick Start.................................................... 4-31 4-2

Overview Overview The Internet offers many valuable resources, often free and open to all users. In addition, it allows businesses and consumers to reach each other more easily than ever before. A connection to the Internet is practically mandatory for most organizations. However, the very advantages of the Internet widespread access pose risks to private organizations. Whenever you connect your network to an untrusted network such as the Internet, you open the door to hackers, spyware, and malware. At best, viruses and spyware consume only bandwidth and resources, costing your organization time and money. At worst, viruses can destroy mission-critical data, spyware can intercept passwords, and hackers can steal proprietary information and hijack network devices. Firewalls protect a private network from these very real threats while allowing an organization to profit from a public network s benefits. A firewall is a collection of components configured to enforce a specific access control policy between your internal (trusted) network and any other (untrusted) network. A firewall filters incoming and outgoing packets to ensure that only authorized packets pass. Often, a firewall can filter packets at several Open Systems Interconnection (OSI) levels and can enforce complex, customized policies. Firewalls are most often used to secure a private network that connects to the insecure Internet, but they can enforce any access control policy between an internal and external network or even between two remote networks that are part of the same organization. As organizations become increasingly interconnected, the security and flexibility that firewalls provide will only become more important. The ProCurve Secure Router 7000dl Series protects WANs with an industrytested stateful-inspection firewall. Advantages of an Integrated Firewall While firewall software can protect individual PCs, a firewall integrated into a router has several advantages: Software firewalls often use mainstream operating systems. Attackers study such systems for vulnerabilities. These operating systems are more vulnerable to targeted attacks and sporadic lock ups, which can take down your firewall and leave your network unprotected. 4-3

Overview A router firewall protects your network entry points, stopping threats before they get through the router. An integrated firewall is less expensive. A firewall integrated on a router allows an organization to enforce a standard security policy for all hosts. Stateful-Inspection Firewalls A stateful-inspection firewall examines packet content at a number of OSI Layers. It combines aspects of: a packet-filtering firewall a circuit-level gateway an application-level gateway Packet-Filtering Firewall A packet-filtering firewall is a router or computer that runs firewall software that has been configured to screen incoming and outgoing packets. Operating at the Network Layer (Layer 3) of the OSI model, a packet-filtering firewall accepts or denies packets based on information contained in the packet s TCP and IP headers. (See Figure 4-1.) You must establish the rules against which a packet-filtering firewall compares the full association of the packets. A packet s full association includes the following information: source address destination address application or protocol source port number destination port number When you define rules, you specify which packets should be allowed and which should be discarded. For the Secure Router OS firewall, these rules are called access control lists (ACLs) and access control policies (ACPs). 4-4

Overview Packet 1 Permitted source IP Packet 1 Internet Router Packet 2 Denied source IP Packet 2 Private network Figure 4-1. Packet-Filtering Firewall ACLs specify certain settings for packets full association information. For example, the ACL can permit packets from a range of IP addresses destined to a specific IP address on a specific port. You then configure ACPs that either allow or discard packets selected by the ACL. For example, you can create ACPs that will drop packets from specific untrusted servers that are identified by their IP addresses. You can also create ACPs that permit particular types of connections (such as FTP connections, identified by destination port) only if they are using the appropriate trusted servers (such as the FTP server, identified by source address). The Secure Router OS firewall s packet-filtering capabilities are among its most important and most flexible functions. Clearly, the specific traffic that the router should allow and block depends on your organization s addressing scheme and security policies. You can configure the router s firewall to behave in a wide variety of ways, including: allowing all traffic between two remote trusted sites blocking all inbound traffic except that to a Web server allowing all outbound traffic and blocking all inbound traffic For information on how to configure packet filtering, see Chapter 5: Applying Access Control to Router Interfaces. 4-5

Overview Circuit-level Gateway A circuit-level gateway acts at the OSI Session Layer (Layer 5) to monitor the establishment of sessions between trusted and untrusted devices. Some circuit-level gateways establish proxy sessions to untrusted hosts for their clients. Attack Checking. A circuit-level gateway monitors TCP handshakes between trusted clients or servers and untrusted hosts to determine whether or not a requested session is legitimate. A circuit-level gateway authorizes a requested session only if the SYN (synchronize) flags, ACK (acknowledge) flags, and sequence numbers involved in the TCP handshake are logical. In addition, the client must meet basic filtering criteria before the gateway accepts the session request. For example, Domain Name System (DNS) must be able to locate the client s IP address and associated Web address. Valid but illogical handshakes are often the sign of an attacker attempting to infiltrate or gain information about a private network, as are packets with invalid IP addresses. The ProCurve Secure Router OS firewall automatically recognizes the flags that mark common attacks and drops packets that contain them. See Configuring Attack Checking on page 4-14 for information on how to enable certain attack checks. Proxy Server. A circuit-level gateway can also act as a proxy server to establish a connection between internal and external hosts. All outgoing packets from the trusted clients appear to have the proxy server s source IP address. A proxy server can be processor intensive because it requires two sessions (one between the internal host and the router and one between the router and the external host). (See Figure 4-2.) Although the stateful-inspection firewall on the ProCurve Secure Router does not act as a proxy server, you can configure network address translation (NAT) to provide some of the same services. Using NAT, the firewall translates the private source addresses in packets headers into a public address. However, unlike a proxy server, the ProCurve Secure Router acts transparently; the session is between the internal and external host, not between each host and the router. (See Figure 4-2.) 4-6

Overview Circuit-level gateway Router A Internet 192.168.1.99 10.1.1.1 Session Session Secure Router OS firewall Router A Internet 192.168.1.99 10.1.1.1 Session Source IP NATed 192.168.1.99 10.1.1.1 Figure 4-2. Circuit-Level Gateway Versus Secure Router OS Firewall For information on how to configure NAT, see Chapter 6: Configuring Network Address Translation. Application-level Gateway Like a circuit-level gateway, an application-level gateway acts as a proxy server between a trusted client and an untrusted host. Application-level proxies filter packets at the OSI Application Layer (Layer 7). That is, they accept only packets generated by services they are designed to copy, forward, and filter. For example, only a Telnet proxy can copy, forward, and filter Telnet traffic. The proxy server reads each packet and filters particular commands or information relating to applicable application protocols. Each protocol needs its own proxy; the proxies themselves are sometimes called application-level gateways (ALGs). For example, an FTP ALG regulates an FTP session between a trusted and untrusted host. Application-level gateways can be prohibitively draining on resources. Each protocol needs a separate ALG, and the gateway imposes two separate connections (from the trusted network to the gateway and from the gateway to the trusted network). 4-7

Overview A stateful-inspection firewall, like that on the ProCurve Secure Router, can analyze Application Layer data without having to act as a proxy server. Instead, the firewall monitors sessions between hosts in the trusted and untrusted networks. When it determines that a session between an untrusted and trusted host is valid and allows the session to be established, the firewall uses algorithms to process the Application Layer data for packets associated with the session. When new packets associated with the session arrive, the stateful-inspection firewall compares the bit patterns of new packets to the bit patterns stored for previously authorized packets. The firewall can then determine whether the new packets are a valid part of the session. The Secure Router OS firewall incorporates several ALGs to allow select applications to punch through the firewall. For example, some applications may send traffic on one port and receive it on another, behavior that the firewall would usually consider suspicious. When an ALG is enabled on the Secure Router OS firewall, the firewall tracks connections made by the application and permits this special behavior. See Configuring ALGs on page 4-18 for information on how to configure ALGs. Table 4-1 summarizes the features of the Secure Router OS Firewall and directs you to the section of the guide that details configuring that feature. Table 4-1. Secure Router OS Firewall Firewall Feature OSI Layer Function ProCurve Secure Router Configuration See packet-filtering Network (3) screens all incoming packets based on source and destination IP addresses and port numbers discards traffic not allowed by the router s access policy configure ACLs and ACPs Chapter 5: Applying Access Control to Router Interfaces circuit-level gateway Session (5) checks that TCP and UDP packets have valid flags and logical sequence numbers discards packets with patterns associated with attacks acts as a proxy server (not supported on the ProCurve Secure Router) enable attack checks configure NAT to provide some of the same services as a proxy server Configuring Attack Checking on page 4-14 Chapter 5: Applying Access Control to Router Interfaces 4-8

Overview Firewall Feature OSI Layer Function ProCurve Secure Router Configuration See application-level gateway Application (7) allows a specific application to work correctly in the presence of the firewall enable ALGs Configuring ALGs on page 4-18 Attack Checking This chapter focuses on configuring the Secure Router OS firewall to block attacks. It also discusses how to disable optional firewall ALGs. For information on how to configure the firewall s packet-filtering and NAT capabilities, see Chapter 5: Applying Access Control to Router Interfaces and Chapter 6: Configuring Network Address Translation. The Secure Router OS firewall automatically detects and blocks specific known attacks, such as SYN floods, ping of death, IP spoofing, Internet Control Message Protocol (ICMP) floods, and falsified IP headers. It monitors TCP handshakes and drops packets with flags that signal known attacks. The Secure Router OS firewall automatically checks for these attacks: Ping of death Syndrop Targa Nestea Newtear TearDrop Opentear Bonk Boink Smurf attack IP spoofing Twinge Jolt Jolt2 Chargen Fraggle Land attack SYN-flood 4-9

Overview The firewall also checks for TCP SYN packets with ACK, URG, RST, or FIN flags and packets: with the broadcast address for the source address with an invalid TCP sequence number with an enabled source route option You do not have to configure the firewall to screen these attacks; it does so as soon as you enable it. Equally, you cannot prevent the firewall from dropping packets that display the signs of these attacks. However, you can enable and disable certain optional checks, including those for: SYN-flood attacks WinNuke attacks reset attacks You can also enable the router to check for attacks on reflexive traffic. You will learn how to do so in Configuring Attack Checking on page 4-14. ProCurve periodically updates the Secure Router operating system (SROS) to block new attacks as these attacks are reported. You can download new SROS software at www.hp.com/rnd/software/securerouters.htm. See the Basic Management and Configuration Guide, Chapter 1: Overview to learn how to update the software. SYN-flood Attacks SYN-flood attacks exploit the process of establishing a TCP/IP session. In a normal session, the initiator sends a SYN packet, the responder returns a SYN/ ACK packet, and the initiator replies with an ACK packet. In a SYN-flood attack, the attacker repeatedly sends SYN packets, but does not reply to the responder s SYN/ACKs. The responder holds the TCP connection open, waiting for ACKs that do not come. Eventually, the SYN-flood attack uses all of the target host s resources, creating a Denial of Service (DoS). (See Figure 4-3.) A variation of this attack creates another victim. Rather than using an unreachable source address, the attacker uses IP spoofing to make the packet appear as if it were sent from a legitimate system. The target host then begins sending SYN/ACK packets to this system, which was not involved in the attack. The attacker can then create havoc on two or even more systems at once. 4-10

Overview SYN Source: 192.168.3.4 /32 SYN/ACK Attacking system SYN Source: 172.16.1.26 /32 SYN Source: 10.0.3.28 /32 no route SYN/ACK no route SYN/ACK no route Target host Figure 4-3. Syn-flood Attack The result of both attacks is extremely degraded performance or, worse, a system crash. Because SYN packets are a legitimate part of establishing a session, the Secure Router OS firewall cannot simply screen out these packets. However, the Secure Router OS firewall does monitor session establishment to ensure that a client is legitimate. This attack check is enabled by default. However, you can also disable it. WinNuke Attacks The WinNuke attack is launched by sending out-of-band (OOB) data to port 139. Windows NT 3.51 and 4.0 systems crash, while Windows 95 and Windows 3.11 systems display the blue screen, indicating that the system is in an extreme state. The WinNuke attack does not usually cause permanent damage, although network connectivity is lost and any open applications crash. To recover, the user simply reboots the PC. The Secure Router OS firewall does not automatically block WinNuke attacks. However, if your network includes these systems, you may want to enable the WinNuke attack check. 4-11

Overview Reflexive Traffic Reflexive traffic is traffic that is received on an interface and then forwarded out the same interface. For example, in a multi-netted environment, traffic will sometimes arrive on and leave by the same Ethernet interface. Figure 4-4 shows an example of such a network. (The interface has a primary and secondary IP address and routes between the two subnets.) By default, the Secure Router OS firewall does not process traffic that it immediately forwards through the interface on which the traffic was received. It assumes that the traffic is from a trusted source. Router 1 Hub Router 2 Eth 0/1 10.2.2.253 /24 Destination: 10.2.2.253 Eth 0/1 10.1.1.254 /24 10.2.2.254 /24 10.1.1.1 /24 Default gateway: 10.1.1.254 Figure 4-4. Reflexive Traffic If you want the Secure Router OS firewall to process traffic sent from a primary subnet to a secondary subnet on the same interface, you must enable the reflexive-traffic check. When you enable this check, the Secure Router OS firewall will screen reflexive traffic for attacks. (It will also apply any ACPs assigned to the interface.) Event Logging The Secure Router OS firewall automatically logs events that occur on the router. The firewall can log the events to: an event-history log on the router a syslog server an email address or addresses 4-12

Overview You can examine logs to look for information to help you in troubleshooting or to see what kind of attacks have been targeted at your system. (You can also view events as they occur on the terminal by activating the events command from the enable mode context.) Events include: blocked attacks policy matches (packets filtered by an ACL or ACP) an interface going down or up WAN alarms PPP sessions opening and closing Frame Relay permanent virtual circuits (PVCs) that are becoming active or inactive or being deleted The router classifies events according to their priority. From those of least to those of greatest concern, event priorities are: informational notification warning error fatal You can configure the Secure Router OS firewall to log events of different priorities to different destinations. For example, you can have the firewall log all events to the router s event history log, but only email you logs for error and fatal events. 4-13

Configuring Attack Checking Configuring Attack Checking To configure the Secure Router OS firewall to block attacks, you only have to: enable the firewall You can also: enable and disable optional checks check reflexive traffic enable stealth mode Enabling the Secure Router OS Firewall To enable the firewall, enter the following command from the global configuration mode context: ProCurve(config)# ip firewall When the Secure Router OS firewall is enabled, it automatically blocks the attacks and types of packets shown in Table 4-2. Table 4-2. Packets Automatically Dropped by the Secure Router OS Firewall Packet Associated Attack larger than the IP max (65,535 bytes) fragmented packets with errors when reconstructed ping response that is not part of an active session source address does not match any of the routes for interface on which the packet arrived Ping of death Syndrop Targa Nestea Newtear TearDrop Opentear Bonk Boink Smurf attack IP spoofing 4-14

Configuring Attack Checking Packet all ICMP packets except: echo echo-reply ttl expired destination unreachable quench falsified IP header (the length bit does not match the actual length) Associated Attack Twinge Jolt Jolt2 UDP echo packets Chargen Fraggle source address equals the destination address broadcast address is the same as the source address TCP SYN packets with one or more of these flags: ACK URG RST FIN Land attack invalid TCP sequence number source route option is enabled You cannot force the router to accept any of these packets. Enabling and Disabling Optional Attack Checks You enable the Secure Router OS firewall to check for optional attacks with this command: Syntax: ip firewall check [winnuke syn-flood reflexive-traffic] Use the winnuke option to have the firewall drop TCP packets with the URG flag set. This blocks: the WinNuke attack the TCP Xmas scan 4-15

Configuring Attack Checking The WinNuke attack affects Windows NT 3.51 and 4.0, Windows 95, and Windows 3.11. It does not usually cause permanent damage. However, it can cause open Windows applications to crash and hosts to lose connectivity; you should consider enabling this check when your network uses affected systems. An attacker sends a SYN-flood to create a DoS attack. A SYN-flood consists of the TCP packets used to establish legitimate sessions; however, the source of the flood does not respond to the router s SYN/ACKs. The router uses all its resources waiting to open the unresolved sessions. Because the router cannot simply drop all SYN packets, the majority of which are legitimate, it must protect against the attack in a different way. The ProCurve Secure Router guards against SYN-floods by monitoring the establishment of TCP sessions, which can require increased processing power. The firewall guards against SYN-flood attacks by default. You can disable the check by entering: ProCurve(config)# no ip firewall check syn-flood By default, RST sequence checks are also enabled. When a host receives a TCP packet with its RST bit set, it resets the session associated with that packet. In a RST reset attack, a hacker sets the RST bit in a TCP packet that spoofs the IP addresses, port numbers, and sequence numbers of a legitimate TCP session. The spoofed session resets, causing a DoS, which can be particularly damaging for protocols such as Border Gateway Protocol (BGP) that require constant TCP connections. When the RST sequence check is enabled, the Secure Router OS firewall only accepts TCP RST packets that have the correct sequence number, significantly reducing the chance that an attacker can spoof a packet successfully. To disable or re-enable the RST sequence check, enter this command from the global configuration mode context: Syntax: [no] ip firewall check rst-seq Checking Reflexive Traffic Reflexive traffic is traffic that is received on an interface and then forwarded out the same interface. For example, in a multi-netted environment, an Ethernet interface has a primary and secondary IP address and routes between the two subnets. Therefore, some traffic will arrive on and leave by the same Ethernet interface. (See Figure 4-5.) By default, the Secure Router OS firewall 4-16

Configuring Attack Checking does not process traffic that it immediately forwards through the interface on which the traffic was received. It assumes that the traffic is from a trusted source. Router 1 Hub Router 2 Eth 0/1 10.2.2.253 /24 Destination: 10.2.2.253 Eth 0/1 10.1.1.254 /24 10.2.2.254 /24 10.1.1.1 /24 Default gateway: 10.1.1.254 Figure 4-5. Reflexive Traffic If you want the Secure Router OS firewall to process traffic sent from a primary subnet to a secondary subnet on the same interface, you must enable the reflexive-traffic check. When you enable this check, the Secure Router OS firewall will screen reflexive traffic for attacks. If your organizations uses ACPs to control access for local networks, you should enable checks on reflexive traffic, even if the router does not need to check for attacks. The firewall must be active in order to enforce an ACP on an interface. Enter the following command: ProCurve(config)# ip firewall check reflexive Configuring Stealth Mode Attackers can detect the ports that you have closed on a router using port scanners. The port scanners attempts to initiate a TCP session on all ports. Typically, the router would reply with an RST packet when a port is closed. In this way, the hacker can map out closed ports and, inversely, open ports. The ProCurve Secure Router can conceal closed ports from port scanners by refusing to send RST packets. You enable this function with this global configuration mode command: ProCurve(config)# ip firewall stealth Stealth mode is disabled by default. 4-17

Configuring ALGs Configuring ALGs ALGs monitor sessions on the OSI Application Layer. An ALG helps a firewall read packets and filter them for the particular commands or information relating to the ALG s application. Each application has a distinct ALG that deals with its special concerns. Some applications must have an ALG to function in the presence of a firewall. For example, the application may exhibit behavior that the firewall considers suspicious. Without an ALG, the firewall would drop suspicious packets and the application would not work. Some applications receive data on one port and send it out on another. An ALG monitors this process so that you do not have to configure the firewall to allow traffic on both ports. Figure 4-6 illustrates how the FTP ALG allows traffic to the FTP server on port 20 and from the server on port 21. Router 20 FTP server FTP client 21 Figure 4-6. FTP ALG The Secure Router OS firewall supports ALGs for the following applications: File Transfer Protocol (FTP) H.323 Session Initiation Protocol (SIP) Point-to-Point Tunneling Protocol (PPTP) If your WAN uses any of these protocols and the router s firewall is enabled, the corresponding ALG must also be enabled. The FTP, SIP, and PPTP ALGs are enabled by default. You can also disable them. In addition, you can enable the H.323 ALG, which is disabled by default. 4-18

Configuring ALGs Enabling the FTP ALG FTP allows computers to exchange files through the Internet. It is often used to upload Web pages to a Web server or to download files from a server to a PC. You can disable the FTP ALG if your company wants to prohibit users from downloading files from the Internet. Enter: ProCurve(config)# no ip firewall alg ftp If your company decides to allow the use of FTP, accept the default setting. Rather than allowing or disallowing FTP entirely, you can limit FTP applications to certain users. First, enable the FTP ALG: ProCurve(config)# ip firewall alg ftp Then configure an ACL that permits authorized users and apply the ACL to FTP data. See Chapter 5: Applying Access Control to Router Interfaces. Enabling the H.323 ALG for Voice and Videoconferencing H.323 is an International Telecommunication Union (ITU) standard that defines how voice and videoconferencing applications operate over packetswitched networks, including the Internet. By default, the H.323 ALG is disabled on the ProCurve Secure Router. If your organization uses applications based on this standard, you should enable the ALG with this command entered from the global configuration mode context: Syntax: ip firewall alg h323 Disable the ALG with this command: Syntax: [no] ip firewall alg h323 Enabling the SIP ALG for Voice over IP SIP is an Internet Engineering Task Force (IETF) signaling standard for multimedia sessions such as Voice over IP (VoIP). Many VoIP vendors are creating new applications based on the SIP standard rather than on H.323. If your organization is using such applications, you should accept the default setting of enabled for this ALG. Use this command to enable or disable the SIP ALG: Syntax: [no] ip firewall alg sip [udp <port number>] 4-19

Configuring ALGs On the ProCurve Secure Router, the default port number that the ALG uses for SIP is 5060. If any SIP applications in your network use different port numbers, then you must enable those ports as well. Use the optional udp keyword and enter the port number. (The number can be between 0 and 65,535.) For example: ProCurve(config)# ip firewall alg sip udp 5004 ProCurve(config)# ip firewall alg sip udp 5070 The ProCurve Secure Router can act as a SIP proxy server. For more information on this feature, see Enabling SIP Services on page 8-62 in Chapter 8: Setting Up Quality of Service. Enabling the PPTP ALG for VPNs PPTP provides users with secure dial-up access to their Internet service provider (ISP) or company network, creating a virtual private network (VPN). Users establish a VPN in transport mode from their personal workstations (as opposed to in tunnel mode, in which they use a router as a gateway device). If your organization is using PPTP to create VPNs, you should accept the default enabled setting for the PPTP ALG. To re-enable the ALG, enter: ProCurve(config)# ip firewall alg pptp If you want the router to act as a gateway device and establish a VPN for all users using the IP Security (IPSec) standard, you should disable the PPTP ALG. Enter: ProCurve(config)# no ip firewall alg pptp See Chapter 10: Virtual Private Networks to learn how to use the ProCurve Secure Router as a gateway device for a VPN. Enabling Firewall Traversal The RTP protocol may establish a session on an unexpected port. In this case, the firewall will drop return traffic. You can enable firewall traversal to allow all traffic that is part of an established RTP session to pass through the firewall. Enter this command from the global configuration mode context: Syntax: ip rtp firewall-traversal [policy-timeout <seconds>] If so desired, you can specify when the router will timeout the session. Enter a number between 0 and 4294967295 seconds. If you enter 0, then sessions will never timeout. 4-20

Configuring Timeouts for Sessions Configuring Timeouts for Sessions As well as screening TCP and UDP packets for attacks, the Secure Router OS firewall monitors all ICMP, TCP, and UDP sessions established through the router. One of the advantages of a stateful-inspection firewall is that it monitors sessions to ensure that they proceed in a valid and logical fashion. To maintain secure sessions, the firewall times them out after a specified amount of time. The timeout interval is the amount of time the router will keep a session open without the hosts exchanging data. The Secure Router OS firewall also monitors authentication header (AH) and encapsulating security payload (ESP) sessions, which are used with IPSec to establish a secure virtual private network (VPN). The firewall can also monitor generic routing encapsulation (GRE) sessions which are established between tunnel interfaces on remote routers. By default, the Secure Router OS firewall times out: AH sessions after 60 seconds ESP sessions after 60 seconds GRE sessions after 60 seconds ICMP sessions after 60 seconds TCP sessions after 600 seconds (10 minutes) UDP sessions after 60 seconds You can alter these default timeout intervals. You can also set different timeouts for various TCP and UDP applications. For example, you can have Telnet sessions time out after one minute, while Web sessions time out after twelve minutes have passed. Setting the Timeout for a Protocol The timeout interval for AH, ESP, GRE, and ICMP is the timeout interval for all sessions that use that protocol. The timeout interval for TCP and for UDP is the global timeout interval. That is, the interval applies to all applications for which you have not configured a different interval. 4-21

Configuring Timeouts for Sessions The default settings for these timeouts are usually adequate. However, you can alter them in accordance with your organization s policies with this command: Syntax: ip policy-timeout [ahp esp gre icmp] <seconds> Syntax: ip policy-timeout [tcp udp] all-ports <seconds> The timeout interval can range from 0 to 4,294,967,295 seconds. If you set the timeout to 0, sessions will never timeout. For TCP and UDP, you must add the all-ports keyword to specify that this interval is the default timeout for all applications. For example, enter commands such as: ProCurve(config)# ip policy-timeout tcp all-ports 450 ProCurve(config)# ip policy-timeout icmp 120 You can also set a timeout interval for any RTP session. See Enabling Firewall Traversal on page 4-20. Setting Timeouts for Specific TCP and UDP Applications You can set different timeout intervals for various TCP or UDP applications by specifying the protocol port of the application. For example, you can configure the firewall to override the TCP timeout interval and time out Telnet sessions after only one minute. You enter the same command used to set the TCP timeout interval, but you add the port number for the specific application: Syntax: ip policy-timeout [tcp udp] [all-ports <port> range <first port> <last port>] <seconds> You can enter port numbers from 0 to 65,535. (The range for seconds is the same as for the global TCP and UDP commands.) For example, Telnet s TCP port number is 23. You can configure a Telnet session to time out after a minute: ProCurve(config)# ip policy-timeout tcp 23 60 The CLI allows you to enter a keyword instead of a port number for many wellknown applications including Telnet, HTTP, Secure Shell, DNS, and Simple Mail Transfer Protocol (SMTP). 4-22

Configuring Timeouts for Sessions For a complete list of protocol keywords, refer to your SROS CLI reference guide. You can also use the? help command. For example: ProCurve(config)# ip policy-timeout tcp? You can similarly set individual timeouts for a specific UDP application. Again, you specify a port number (from 0 to 65,535), a range of port numbers, or a keyword for a well-known application such as DNS, NetBIOS, Simple Network Management Protocol (SNMP), or Routing Information Protocol (RIP). Use this command: Syntax: ip policy-timeout udp [all-ports <port > range <first port number> <last port number> <keyword> range <first keyword> <last keyword>] <seconds> For example, you can set the timeout for SNMP sessions to 45 seconds: ProCurve(config)# ip policy-timeout udp snmp 45 4-23

Configuring Logging Configuring Logging By default, the Secure Router OS firewall logs events to the router s eventhistory log. It also creates a log for every 100 attacks it blocks and every 100 packets it matches to a policy. To configure the event-history log, you must: specify the priority level for events logged to the event-history You can also: change how many blocked attacks generate a log change how many ACP matches generate a log forward logs to a syslog server forward logs to an email address or addresses Specifying the Priority Level for Logged Events The router s event-history log is enabled by default. However, in order for the firewall to log events to it, you must specify the priority level for logged events. The firewall classifies events into five priority levels according to the risk posed to your system. These levels are: informational (0) notification (1) warning (2) error (3) fatal (4) View Table 4-3 for some examples of events at various priority levels. 4-24

Configuring Logging Table 4-3. Priority Level for Common Events Priority Level informational notification warning Example Events policy matches session login Frame Relay subinterface becoming active or inactive error PPP session opening: LCP going up LLDPCP going up IPCP going up blocked attack fatal PPP session closing: LCP going down LLDPCP going down IPCP going down Frame Relay interface going down WAN alarms: Yellow Red LOS LOF To specify the priority for events the firewall should log, enter the following command followed by the appropriate keyword: Syntax: event-history priority [info notice warning error fatal] The firewall logs all events of the specified priority and greater. For example, to log all events to the event-history, enter: ProCurve(config)# event-history priority info To disable logging to the event history, enter: ProCurve(config)# no event-history on To re-enable logging, enter: ProCurve(config)# event-history on You can specify a different priority for events logged to a syslog server or email address. (See Forwarding Logs to a Syslog Server on page 4-27 and Forwarding Logs to an Email Address on page 4-29.) 4-25

Configuring Logging To examine the logs stored in the event history, enter the following command: ProCurve# show event-history Logs are marked with the date and time at which they occurred. They are also labeled with the type of event. For example, the message can be about the status of a line (E1) or interface (INTERFACE_STATUS). It can be a message from a particular protocol, such as a PPP negotiation message or a DHCPACK message. Examining the event history will often help you to locate the source of a problem, as well as monitor network activity to look for ways to reduce overhead. When troubleshooting a specific problem, you should first clear the event history: ProCurve# clear event-history You can then reproduce the problem and view the event history. Only logs relevant to the problem will appear. If necessary, lower the priority level for logging events and reproduce the problem again. Note The enable mode command, events, is different than the global configuration mode command, event-history on. The first displays events to the terminal as they occur. The second saves these events to an event history, stored on the router, which you can view at any time. Specifying How Many Attacks Generate a Log By default, the firewall generates a log after it blocks 100 attacks. This setting is called the attack log threshold. (An attack log has an error priority.) You can alter this threshold. Set the attack log threshold from the global configuration mode context by entering: Syntax: ip firewall attack-log threshold <number of attacks blocked> You can set the threshold from 1 to 4,294,967,295. For example, you might want to determine the times of day at which your network receives the most attacks. Lowering the threshold lets you zero in more precisely on when attacks actually occur. For example: ProCurve(config)# ip attack-log firewall threshold 10 4-26

Configuring Logging Specifying How Many Policy Matches Generate a Log The Secure Router OS firewall is a stateful-inspection firewall that supports packet filtering. You customize filters, or ACPs, that the firewall uses to determine whether it should forward or drop each packet that arrives on an interface. The firewall automatically produces a log after it matches 100 packets to an ACP. This setting is the policy log threshold. When you apply an ACP to an interface, all packets are filtered. Policy logs show how many packets are dropped and how many are allowed to pass. Dropped packets, unlike those that produce attack logs, do not necessarily have the earmarks of an attack: they are simply to or from hosts that the interface s access policy does not permit. A policy log has an informational event priority. You can monitor the traffic passing through your router by examining the policy logs. As with attack logs, the lower you set the threshold, the more precise, moment-to-moment picture you receive about your system. On the other hand, setting the threshold too low can clutter the event-history log with unnecessary information and consume processing power. To set the policy log threshold, enter: Syntax: ip firewall policy-log threshold <number of matches> You can set the threshold from 1 to 4,294,967,295. For example: ProCurve(config)# ip firewall policy-log threshold 150 Forwarding Logs to a Syslog Server Syslog servers collect information about devices on a network. You can then analyze this information for a picture of network functions as a whole. The ProCurve Secure Router can log events to a syslog server. (See Figure 4-7.) Syslog server local2 Router Log Failed connection Figure 4-7. Forwarding Logs to a Syslog Server 4-27

Configuring Logging To configure log forwarding to a syslog server, you must: 1. Enable log forwarding. From the global configuration mode context, enter: ProCurve(config)# logging forwarding on 2. Specify the IP address of the syslog server: Syntax: logging forwarding receiver-ip <A.B.C.D> For example: ProCurve(config)# logging forwarding receiver-ip 172.16.62.99 3. Configure the syslog facility type: Syntax: logging facility <facility keyword> The default setting is kern. Originally, the syslog facility was used to identify which part of a UNIX system originated a particular message. This system does not define a router as such, but the local0 to local7 facilities are typically reserved for messages from remote devices. The ProCurve Secure Router can set its message facility type to any of those shown in Table 4-4. You should select the facility used by routers in your network. For example, the syslog server in Figure 4-7 is configured to receive logs from the router on facility local2. You would enter: ProCurve(config)# logging facility local2 Table 4-4. Syslog Facilities Syslog Facility authorization system cron facility system daemon kernel locally defined messages line printer system mail system USENET news system use Keyword auth cron daemon kern local0 local7 lpr mail news sys9 sys14 4-28

Configuring Logging Syslog Facility system log user process UNIX-to-UNIX copy system Keyword syslog user uucp 4. Specify the priority level for events that the router forwards to the syslog server: Syntax: logging forwarding priority-level [info notice warning error fatal] For example: ProCurve(config)# logging forwarding priority-level notice The priority level can be the same as or different than that for events logged to the router s event history. The default setting is warning. The router logs all events of that priority level or higher. Caution If you log informational or other low priority events, more processing power is required on the ProCurve Secure Router, and more disk space is required on the syslog server. 5. Forwarded logs, by default, have the source address of the interface used to forward them. If you want all logs to have the same source address, then you must specify a source interface. Use this global configuration mode context command: Syntax: logging forwarding source-interface <interface ID> Forwarding Logs to an Email Address You can also configure the ProCurve Secure Router to send logs to email accounts. In this way, you and other network administrators can check up on a network. Forwarding logs to an email address can also be very useful when troubleshooting a problem between two remote sites. For example, problems with routing protocols may affect an entire WAN. When you can examine events on the remote router in your email, you can more easily troubleshoot the local router. (Of course, if the local router loses total connectivity with a remote router, you will not be able to receive logs from it through a local email server.) You can also configure the router to send exception reports to one or more email addresses. 4-29

Configuring Logging To configure the router to forward event logs to an email address or addresses, you must: 1. Enable log forwarding to an email address. Enter: ProCurve(config)# logging email on 2. Specify the IP address of the email server. You can use either the IP address of the email server or the hostname: Syntax: logging email receiver-ip [<A.B.C.D> <hostname>] For example: ProCurve(config)# logging email receiver-ip 172.16.60.99 3. Specify the email address for the recipient(s) of the logs: Syntax: logging email address-list <email address>;<another email address> More than one person can receive the logs from the ProCurve Secure Router. To specify multiple email addresses, separate each email address with a semi-colon. Do not enter a space between the next email address and the semi-colon that precedes it. You can specify as many email addresses as you want. For example: ProCurve(config)# logging email address-list juan@procurve.com;heidi@procurve.com 4. If you want the router to forward exception reports as well, enter this command: Syntax: logging email exception-report address-list <email address>;<another email address> Enter the email addresses of the people who should receive the exception reports in the same way that you entered addresses for emailed logs. 5. Specify the priority level for events that the router forwards to the email addresses: Syntax: logging email priority-level [info notice warning error fatal] For example: ProCurve(config)# log forwarding priority-level error The priority level can be the same as or different than that for events logged to the router s event history. The default level is warning. 4-30

Quick Start 6. You can also specify what will appear in the From field of the email message by entering: Syntax: logging email sender <source> The message will simply consist of logs without any explanation, so the From field must give recipients enough information to know which device originated the logs. For example, enter: ProCurve(config)# logging email sender admin@procurve.com 7. As with forwarded logs, you can force the router to send all emailed logs (and exception reports) with the same source address. This source address is taken from the interface that you specify with this command: Syntax: logging email source-interface <interface ID> Quick Start This section provides the commands you must enter to quickly: enable the firewall check for optional attacks enable and disable ALGs set policy timeouts configure log forwarding Only a minimal explanation is provided. If you need additional information about any of these options, see Contents on page 4-1 to locate the section and page number that contains the explanation you need. 1. Enable the firewall: ProCurve(config)# ip firewall 2. If so desired, enable the firewall to check for WinNuke attacks: ProCurve(config)# ip firewall check winnuke 3. Enable any necessary ALGs and disable ALGs for applications that your organization does not want hosts to use. FTP, SIP, and PPTP are enabled by default. H.323 is disabled by default: Syntax: [no] ip firewall alg [ftp h323 sip pptp] 4-31

Quick Start 4. Set the priority level for events logged to the router s event history. Syntax: event-history priority [info notice warning error fatal] For example: ProCurve(config)# event-history priority info 5. If so desired, change the timeouts for TCP and UDP and ICMP sessions: Syntax: ip policy-timeout [tcp udp] all-ports <seconds> Syntax: ip firewall policy-timeout icmp <seconds> 6. You can also configure individual timeouts for various TCP and UDP protocols such as Telnet, SNMP, and HTTP. Enter: Syntax: ip policy-timeout [tcp udp] [all-ports <port> range <first port> <last port>] <seconds> You can enter ports as a number or as a keyword: ProCurve(config)# ip policy-timeout [tcp udp]? This command displays a complete list of keywords for well-known ports. 7. If so desired, enable log forwarding to a syslog server. a. Enable log forwarding: ProCurve(config)# logging forwarding on b. Specify the syslog server address: ProCurve(config)# logging forwarding receiver-ip <A.B.C.D> 8. If so desired, enable the router to email events. a. Enable log forwarding to email: ProCurve(config)# logging email on b. Specify the email server address: ProCurve(config)# logging email receiver-ip [<A.B.C.D> <hostname>] c. Specify the email address or addresses: ProCurve(config)# logging email address-list <email address>;<another email address> You can enter any number of email addresses. (Do not put a space between the ; and the next address.) 4-32