Chapter 9. Mitigating Attacks with Screens and Flow Settings
9.0. Introduction
In the world of computer and network security, there are myriad ways to launch an attack, which, from a network perspective, can generically be defined as “traffic that has malicious intent.” There are certainly computer attacks that no firewall can prevent, such as those executed locally on the machine by a malicious user (and those executed on a machine by an implement such as a sledgehammer). Fortunately, however, these types of threats are often handled by a physical security infrastructure. Unfortunately, the network then becomes a convenient launching point for an attack for those without physical access. From the network’s perspective, there are numerous types of attack. Although it’s a vast oversimplification, for the purposes of discussing screens and flow settings, we can group attacks into two types: brute force and precision. ScreenOS has the capability to protect against both types of attack.
Under the category of brute force attacks, perhaps none are better known than those that fall under the Denial of Service classification. Denial of Service (DoS) attacks are one of the most well-known network security threats, largely due to the high-profile way in which they can affect networks. Over the years, some of the largest, most respected Internet sites have been effectively taken offline by DoS attacks, and these events have, not surprisingly, received enough media attention to make DoS attack a household term. A DoS attack typically has a singular focus, namely, to cause the services running on a particular host or network to become unavailable. Some DoS attacks exploit vulnerabilities in an operating system and cause it to crash, such as the infamous Winnuke attack. Others overwhelm a network or device with traffic so that there are no more resources to handle legitimate traffic. This latter type of attack can be particularly challenging to stop. Despite the challenges of stopping these flood attacks, one of the most common desires in implementing a firewall is in fact the ability to stop these attacks. Although ScreenOS has many powerful capabilities in this regard, a large, distributed DoS attack that is launched by hundreds or thousands of compromised hosts may be capable of generating hundreds of megabits per second of traffic. This is likely more bandwidth than is available to the Internet for most organizations, and must therefore be mitigated further upstream in the Inter-net Service Provider’s (ISP’s) networks. The most common flood types of attacks are the SYN flood, User Datagram Protocol (UDP) flood, and Internet Control Message Protocol (ICMP) flood. You can mitigate all of these using the screen settings within ScreenOS.
DoS attacks aimed at end hosts often exploit weaknesses in the underlying operating systems to cause the systems to become unresponsive, to crash, and so forth. These attacks are different from flood attacks because they can often be executed with just one or a few packets. Screens are available for some of the most common attacks in this category, such as the Winnuke, Land, and Teardrop attacks.
Precision attacks often involve a bit more thought than brute force attacks, and typically involve multiple phases, all the way from reconnaissance to machine ownership. Before a precision attack is launched, information about the victim needs to be gathered. This information gathering typically takes the form of various types of scans to determine available hosts, networks, and ports. Ping sweeps are used to determine which hosts are available on a network. Port scans are used to locate available ports on a machine.
Other scans send crafted packets to a victim, often with illegal options, such as having both the SYN and FIN bits set in a Transmission Control Protocol (TCP) packet. When the destination processes these illegal packets, depending on the operating system, different response packets will be generated. By analyzing the response, the attacker can gain valuable information about the host, such as the operating system version, so that he can more effectively tailor his attack strategy. You can use screens to detect and drop these types of malicious traffic.
Another common method of attack is to embed malicious code in data a user may access. This is often performed in a HyperText Transfer Protocol (HTTP) context with executable files, malicious Java™ code, and ActiveX controls. ScreenOS allows you to restrict access to all of these types of traffic.
Screens are configured on a per-zone basis, and they cover a wide variety of attack traffic. Depending on the type of screen being configured, there may be additional settings beyond simply blocking the traffic.
Attack prevention is also a native function of any firewall. ScreenOS handles traffic on a per-flow basis. You can use flows or sessions as a way to determine whether traffic attempting to traverse the firewall is legitimate. You control the state-checking components resident in ScreenOS by configuring “flow” settings. These settings allow you to configure state checking for various conditions on the device. You can use flow settings to protect against TCP hijacking, and to generally ensure that the fire-wall is performing full state processing when desired.
To adequately perform state checking, it is critical that the firewall be able to see both directions of any flow or session. To do this, symmetrical traffic patterns through the firewall are required. When higher-layer inspections are being per-formed, it is even more critical to have symmetric traffic patterns. You can enforce symmetry in a variety of ways, but some of the most common methods are to ensure a single path in and out of the network via deterministic routing using metrics, using Network Address Translation (NAT) to ensure a deterministic return, and using policy-based routing. In some cases, however, such as in virtual private network (VPN) environments, asymmetry may be acceptable as the traffic is already strongly authenticated.
9.1. Configure SYN Flood Protection
Solution
Configure SYN flood protection:
FIREWALL-A->set zone "Trust" screen syn-floodFIREWALL-A->set zone "Trust" screen syn-flood alarm-threshold 250FIREWALL-A->set zone "Trust" screen syn-flood attack-threshold 250FIREWALL-A->set zone "Trust" screen syn-flood source-threshold 250FIREWALL-A->set zone "Trust" screen syn-flood destination- threshold 1000FIREWALL-A->set flow syn-proxy syn-cookie
Discussion
SYN flood protection is one of the most common screens to enable in ScreenOS. A SYN flood is an attack in which the attacker attempts to fill up a server’s connection table with half-open connections. To do this, a large volume of SYN packets is sent to a victim machine, but the full three-way handshake is never completed. These attacks frequently utilize spoofed IP addresses. By default, in ScreenOS, once any of the thresholds configurable under SYN flood screen protection is exceeded, the fire-wall will begin to proxy the SYN-ACK responses on behalf of the client. In doing this, the goal is to prevent the server from running out of sockets. Only when an ACK response is returned to the firewall from a client will the firewall send the original SYN packet to the server. The server will then respond with a SYN-ACK, which the firewall will intercept, and will pass along the ACK packet, completing the three-way hand-shake. The net effect of this is that the firewall allows only valid connections to reach the server while weeding out invalid connection attempts. The major downside of this approach is that it is a very CPU-intensive process.
In more recent versions of ScreenOS, the capability to use SYN cookies which provide a cryptographic method of connection verification was added. By enabling SYN cookie protection at the flow level, you can expect much higher performance when defending against a SYN flood. It is strongly recommended that SYN cookie support be enabled.
As with all screens, SYN flood protection is enabled on a per-zone basis. The first step in configuring SYN flood protection is to enable it on the desired zone. Then, set the alarm and attack thresholds. The alarm threshold differs from the attack threshold so that you can choose to alarm at a different threshold than at that which the attacker drops traffic. You can also define specific thresholds based on the source or the destination address. If either of these is set, the lower of the values will be used. This capability is useful when protecting a server. In this example, the destination threshold is set to 1,000, whereas the source threshold is configured for 250. This is done because no more than 250 SYN packets per second per source are expected; however, up to 1,000 packets per second may be seen as destined to any given IP inside the network. Such a large number of SYN packets might be expected on a busy server farm. Conversely, a large proxy farm may generate very high rates of outbound SYN packets. Because each scenario would likely occur on a different zone on the firewall, it is important that the threshold settings accurately reflect the expected traffic profiles.
To verify the settings, use the getzone <zone name> screen command:
FIREWALL-A-> get zone trust screen
Screen function only generate alarm without dropping packet: OFF.
Screen function apply to traffic exiting tunnels: OFF.
SYN flood protection(100) on
Alarm Threshold: 250
Queue Size : 200
Timeout Value : 20
Source Threshold: 250
Destination Threshold: 1000When a SYN flood is detected, an alarm is generated:
FIREWALL-A-> get alarm eve
Total event entries = 61
Date Time Module Level Type Description
2007-9-10 08:48:26 system emer 00005 SYN flood! From 10.5.5.3:2073
to 192.168.5.1:208, proto TCP
(zone Trust,int bgroup0).
Occurred 1 times.To view the attack counters for a SYN flood, use the get zone command:<zonename> screen attack
FIREWALL-A-> get zone trust screen attack | include "syn flood"
SYN flood protection 4671
SYN Flood(same source) 2164
SYN Flood(same destination) 2507See Also
9.2. Control UDP Floods
Problem
You need to configure UDP flood protection to your DMZ, but you want to host a high-volume Domain Name System (DNS) server.
Solution
Configure UDP flood protection, and configure a separate threshold for the DNS server:
FIREWALL-A->set zone trust screen udp-flood threshold 100FIREWALL-A->set zone trust screen udp-flood dst-ip 192.168.5.1 threshold 1000FIREWALL-A->set zone trust screen udp-flood
Discussion
A UDP flood is a brute force DoS attack in which the attacker sends large volumes of UDP traffic toward a victim with the goal of either disabling the machine or filling up the available bandwidth with attack traffic. ScreenOS defends against UDP floods using a simple threshold value of packets per second, above which all traffic is dropped. UDP flood protection in ScreenOS allows for granular control of attack thresholds without the requirement of separating hosts with different thresholds into different zones. As with SYN flood protection, it is critical to define the thresholds for UDP floods appropriately based on the perspective of the firewall. For example, 100 packets per second of UDP traffic may be high for Internet-bound traffic, but low for traffic destined to a DNS server. Likewise, protocols that are typically found within the confines of an organization, such as the Trivial File Transfer Protocol (TFTP) and NFS, may generate high volumes of packets per second from a particular source compared to commonly found Internet-facing protocols such as DNS. In this recipe, separate thresholds are configured for the DNS server at 192.168.5.1, and all other hosts. This allows the DNS server to receive a much larger volume of traffic. You can easily verify the settings using the getzone command:<zone name> screen
FIREWALL-A->get zone trust screenScreen function only generate alarm without dropping packet: OFF. Screen function apply to traffic exiting tunnels: OFF.UDP flood protection(100)on 192.168.5.1(1000) on SYN flood protection(100) on Alarm Threshold: 100 Queue Size : 200 Timeout Value : 20 Source Threshold: 100 Destination Threshold: 1000
As you can see, the default threshold for any devices except for 192.168.5.1 is 100, as indicated by the 100 in parentheses. 192.168.5.1 has its threshold configured at 1,000 so that it can receive much more traffic. You can view UDP flood information in much the same way as SYN flood information. You generate alarm logs when UDP floods are detected:
FIREWALL-A-> get alarm eve
Total event entries = 1079
Date Time Module Level Type Description
2007-9-10 09:09:44 system alert 00012 UDP flood! From 10.5.5.3:60196
to 192.168.5.1:879, proto UDP (zone
Trust, int bgroup0). Occurred 1 times.Likewise, the get zone <zone name> screen attack command shows the counters for the number of times UDP floods were detected:
FIREWALL-A-> get zone trust screen attack | include udp
UDP flood protection 3603You can also verify that traffic is being dropped using debug flow basic:
FIREWALL-A->get ffilterFlow filter based on: id:0 src ip 10.5.5.3 dst ip 192.168.5.1 id:1 src ip 192.168.5.1 dst ip 10.5.5.3 FIREWALL-A->debug flow basic****** 2500293.0: <Trust/bgroup0> packet received [28]****** ipid = 19403(4bcb), @031d2970 screen detection drop packet.
As each dropped packet will deliver another debug message, you should use this capability with care.
See Also
9.3. Detect Scan Activity
Solution
Use screens to detect port scans and network sweeps:
FIREWALL-A->set zone "Trust" screen port-scanFIREWALL-A->set zone "Trust" screen ip-sweepFIREWALL-A->set zone "Trust" screen ip-sweep threshold 20000FIREWALL-A->set zone "Trust" screen port-scan threshold 20000
Discussion
In ScreenOS, you use scan detection to detect and stop malicious reconnaissance activity. Scanning tools such as Nmap and Nessus are well known and widely deployed. Scans are typically used to find hosts to attack, but they can have a nasty side effect as well. A particularly aggressive scan can consume resources in the form of firewall sessions. You can detect and prevent against two types of scans: IP sweeps and port scans. IP sweep attacks use ping packets to determine which IP addresses on a network have active hosts. An attacker uses a port scan to determine which ports are listening on a particular host so that the services using these ports can be attacked. The threshold values configured for scan detection represent a value in microseconds. The scan detection screens trigger once 10 packets are seen within the interval represented in the threshold value. In this case, 20,000 microseconds is chosen as the interval, which translates to 20 milliseconds. Therefore, if 10 pings are detected within 20 milliseconds, the “IP-sweep” alarm should trigger. Use the get alarm event command to verify:
FIREWALL-A-> get alarm event
Total event entries = 69
Date Time Module Level Type Description
2007-9-12 01:43:29 system alert 00017 Address sweep! From 10.5.5.3
to 192.168.5.66, proto 1 (zone Trust,
int bgroup0). Occurred 1 times.Likewise, the port scan alarm should trigger when 10 packets are seen in a 20-millisecond interval to a particular host. Again, use the get alarm event command to verify:
FIREWALL-A-> get alarm event
Total event entries = 73
Date Time Module Level Type Description
2007-9-12 02:05:38 system alert 00016 Port scan! From 10.5.5.3:1666
to 192.168.5.1:563, proto TCP (zone
Trust, int bgroup0). Occurred 1 timesOnce the tenth packet has been detected within the 20-millisecond window, the fire-wall will begin to drop packets. You can see this in debug flow basic:
****** 2647913.0: <Trust/bgroup0> packet received [28]****** ipid = 57932(e24c), @03141170 screen detection drop packet. POLL_DROP_PAK: vlist 0x1c7d8d0, 0x1c7d8cc
Using screens to detect and drop scan activity can obfuscate the views an attacker has of the network and limit his information about the network and services running on it. The get zone <zone name> screen attack command shows the number of times each screen detection was triggered:
FIREWALL-A->get zone trust screen attack | include portPort scan protection 472 FIREWALL-A->get zone trust screen attack | include sweepIP sweep protection 468
9.4. Avoid Session Table Depletion
Solution
Use source- and destination-based session limits:
FIREWALL-A->set zone "Trust" screen limit-session source-ip- based 128FIREWALL-A->set zone "Trust" screen limit-session destination-ip- based 1000FIREWALL-A->set zone "Trust" screen limit-session
Discussion
Sometimes, attackers attempt to deplete the firewall’s session table, which always consists of a finite set of resources. A simple way to do this is to send a large volume of legitimate traffic, each session of which the firewall must track. If the firewall’s session table becomes full, no new traffic will be permitted through the device, and a DoS will have been successfully executed.
Source-and destination-based session limits are tools for limiting the firewall resources consumed by a particular host. Depending on the size of the firewall and the deployment scenario, this number may vary considerably. You can also use source-and destination-based session limits to limit the spread of worms and to protect device resources from overutilization. They are a handy way to catch a number of unknown problems, and you can utilize them within Virtual Systems (VSYS) as well. As with the other flood-based screen detections, you should configure the limit-session screen with the limits, and then enable it in the desired zone(s). When the source IP-based session threshold is configured, the firewall will not allow more than the threshold number of sessions through from any particular source IP. When you use the source IP-based threshold of 128, once a particular source IP address attempts to send more than 128 sessions’ worth of traffic through the firewall, all further sessions will be disallowed.
The source IP-based screen is often used on trusted networks to limit client activity. Worms, spyware, and other types of malware often cause a host to open a significant number of sessions outbound. Using source IP-based session thresholds can minimize the impact of these types of malware, and allow for simpler detection of their presence.
Both types of screens are particularly useful in VSYS environments where session limits can be enforced per VSYS to prevent a particular VSYS from consuming all of the device’s session resources. As with other screen alerts, use the get alarm event command to view when the limit session screen has triggered:
FIREWALL-A-> get alarm event Date Time Module Level Type Description 2007-9-12 02:36:27 system crit 00033 Src IP session limit! From 10.5.5.3:1594 to 10.50.40.24:631 , proto TCP (zone Trust, int bgroup0). Occurred 1 times.
Likewise, you can use debug flow basic to view packets when they are being dropped:
FIREWALL-A-> get db str
****** 2649415.0: <Trust/bgroup0> packet received [28]******
ipid = 8219(201b), @031d2170
packet passed sanity check.
bgroup0:10.5.5.3/40197->192.168.5.63/3117,1(8/0)<Root>
no session found
flow_first_sanity_check: in <bgroup0>, out <N/A>
packet dropped, drop by firewall check
POLL_DROP_PAK: vlist 0x1c7d8d0, 0x1c7d8d0Finally, use the get zone <zonename> screen attack command to view counters for the screens:
FIREWALL-A-> get zone trust screen attack | include limit
Src IP-based session limiting 114
Dst IP-based session limiting 14989.5. Baseline Traffic to Prepare for Screen Settings
Problem
You want to implement screens for attack protection, but you don’t want to drop legitimate traffic.
Solution
Configure the zone to alarm on attacks, but not to drop the traffic:
FIREWALL-A->set zone untrust screen icmp-flood threshold 10FIREWALL-A->set zone untrust screen icmp-floodFIREWALL-A->set zone untrust screen alarm-without-drop
Discussion
Baselining network traffic should be considered a requirement for any network. It is a necessary step toward being able to plan for capacity upgrades, and to proactively address performance and security problems. A full baselining program involves multiple tools, such as SNMP managers and flow collectors. The ScreenOS MIB aids this effort by providing not just bandwidth information, but also session information.
Outside of the MIBs, ScreenOS has one tool for baselining in the realm of screen protection. Although there is often a very strong desire to stop DoS attacks, it can be a challenge, especially in a complex environment, to identify what is legitimate traffic and what is not. When implementing screens for the first time, configuring the zone to alarm without dropping the traffic is one way to determine what appropriate thresholds are without affecting legitimate traffic. It should be noted, however, that there are restrictions in current code with the alarm-without-drop function. Specifically, the following screen protections are not supported for this function:
SYN-ACK-ACK Proxy Protection
Mal-URL
Session Limit
Block Java Component
Block ActiveX Component
Block ZIP Component
Block EXE Component
Additionally, on the ASIC-based platforms, such as the ISG and NS5000, no screens handled by the ASIC support the alarm-without-drop function. These screens include UDP and ICMP flood. You should consult the latest product documentation to ensure that the feature is supported based on the software and hardware being run. If the feature is not supported, you should use standard network baselining techniques.
By only alarming, you can investigate the source of an alarm before determining that traffic is illegal and dropping it. This way, if there are high volumes of legitimate traffic, you can configure the threshold appropriately before traffic is interrupted. Let’s take an example of a host that is doing performance testing using high volumes of ICMP:
computer:~ me$ sudo ping -f 10.5.5.2 Password: PING 10.5.5.2 (10.5.5.2): 56 data bytes .................................................................. .................................^C --- 10.5.5.2 ping statistics -- 2415 packets transmitted, 2415 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.182/28.205/124.619/19.788 ms
In normal conditions, packet loss in a complete flood to the test host is 0 percent. Now, enable ICMP flood screening for this zone using a low threshold on the theory that there should never be more than 10 packets per second of ICMP traffic:
FIREWALL-A->set zone untrust screen icmp-flood threshold 10FIREWALL-A->set zone untrust screen icmp-flood
Running the same ICMP test, things now look very bad:
computer:~ me$ sudo ping -f 10.5.5.2 PING 10.5.5.2 (10.5.5.2): 56 data bytes ................................................................... ................................................................... ................................................................... ................................................................... ................................................................... ...^C --- 10.5.5.2 ping statistics -- 449 packets transmitted, 33 packets received, 92% packet loss round-trip min/avg/max/stddev = 4.183/4.699/6.813/0.575 ms
Here, notice that the packet loss from the ping flood test is 92 percent, whereas in normal conditions, it is 0 percent. Enabling the alarm-without-drop capability fixes the situation:
FIREWALL-A-> set zone untrust screen alarm-without-drop
computer:~ me$ sudo ping -f 10.5.5.2
PING 10.5.5.2 (10.5.5.2): 56 data bytes
..................................................................
..................................................................
..................................................................
...^C
--- 10.5.5.2 ping statistics --
3875 packets transmitted, 3875 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.968/52.030/168.209/25.480 ms
FIREWALL-A-> get alarm eve
Date Time Module Level Type Description
2007-9-10 06:44:55 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 505
times.
2007-9-10 06:44:54 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 740
times.
2007-9-10 06:44:53 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 847
times.
2007-9-10 06:44:52 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 797
times.
2007-9-10 06:44:51 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 712
times.
2007-9-10 06:44:50 system alert 00011 ICMP flood! From 192.168.5.1 to
10.5.5.2, proto 1 (zone Untrust,
int ethernet0/0). Occurred 240
times.
Total entries matched = 8As hoped, the alarm threshold is still being triggered, but no traffic is being dropped. Next, configure a higher threshold to accommodate the test traffic. Notice from the alarm that the highest one-second interval of testing delivered 847 packets. To be safe, add a little bit of headroom, and configure the ICMP threshold for this zone to be 1,000:
FIREWALL-A->set zone untrust screen icmp-flood threshold 1000FIREWALL-A->set zone untrust screen icmp-flood
Clear the alarms for readability:
FIREWALL-A-> clear alarm eventRerun the test:
computer:~ me$ sudo ping -f 10.5.5.2 Password: PING 10.5.5.2 (10.5.5.2): 56 data bytes .................................................................. .................................................................. .................................................................. .................................................................. .................................................................. ................................^. --- 10.5.5.2 ping statistics -- 8050 packets transmitted, 8050 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.957/52.285/171.744/33.065 ms FIREWALL-A-> get alarm eve No entry matched.
Because no more alarms are being generated, disable the alarm-without-drop function to begin protecting against ICMP floods:
FIREWALL-A-> unset zone untrust screen alarm-without-dropAlthough this recipe dealt with the subject of floods, when enabling screens on a zone, it is always a good idea to set alarm-without-drop initially so that any unexpected but legitimate traffic is not dropped. By following this practice, you can properly investigate unusual traffic.
See Also
9.6. Use Flow Configuration for State Enforcement
Problem
You need to ensure stateful traffic processing and send TCP resets for out-of-state traffic on an interface.
Solution
Use flow configuration to ensure that state checking is enabled:
FIREWALL-A->set flow tcp-syn-checkFIREWALL-A->unset flow no-tcp-seq-checkFIREWALL-A->set zone untrust tcp-rst
Discussion
ScreenOS uses the concept of flow in its configuration to decide how to deal with issues of state. The first command in this recipe forces the firewall to ensure that a full three-way handshake is completed before a session is created on the firewall. By ensuring that a full three-way handshake is completed, a form of source authentication is performed as only sources responding with a valid ACK packet create full sessions. The administrator can also choose to create sessions just based on the existence of the SYN flag in a packet. The command to check just the first packet by validating the existence of the SYN flag is set flow tcp-syn-bit-check. The second command is worded in a somewhat tricky manner. When no-tcp-seq-check is unset on the firewall, TCP sequence checking is enabled, in a splendid example of a double negative. In all recent versions of ScreenOS, SYN checking and sequence checking are enabled by default, so the first two commands in this recipe should not be necessary. Nevertheless, it doesn’t hurt to specifically enable the commands. You can verify the settings with the get flow command:
FIREWALL-A->get flowflow action flag: 00b5 flow GRE outbound tcp-mss is not set flow GRE inbound tcp-mss is not set. flow change tcp mss option for all packets is not set flow change tcp mss option for vpn packets = 1350 flow deny session disabled TCP syn-proxy syn-cookie disabled Allow dns reply pkt without matched request : NOCheck TCP SYN bit before create session & refresh session only after Tcp 3 way handshake : YES Check TCP SYN bit before create session : YES Check TCP SYN bit before create session for tunneled packets : YESUse Hub-and-Spoke policies for Untrust MIP traffic that loops on same interface Check unknown mac flooding : YESSkip sequence number check in stateful inspection : NOICMP path mtu discovery : NO ICMP time exceeded : NO TCP RST invalidates session immediately : NO flow log info: 0.0.0.0/0->0.0.0.0/0,0 flow initial session timeout: 20 seconds flow session cleanup time: 2 seconds early ageout setting: high watermark = 100 (8064 sessions)
Out-of-state packets are not explicitly logged in ScreenOS. In cases where there is an asymmetric traffic pattern, out-of-state packets can result, and you can detect them using debug. The debug flow drop- command will provide information about these packets:
FIREWALL-A-> get db str
packet dropped, first pak not sync
2501359.0: ethernet0/0:192.168.2.33/1->10.5.5.2/1,6<Root>Use debug flow basic with flow filters for more detailed output:
FIREWALL-A->set ff dst-ip 10.5.5.2filter added FIREWALL-A->set ff src-ip 10.5.5.2filter added FIREWALL-A->debug flow basicFIREWALL-A->get db str****** 2501635.0: <Untrust/ethernet0/0> packet received [40]****** ipid = 0(0000), @03080c90 packet passed sanity check. ethernet0/0:192.168.2.33/1->10.5.5.2/1,6<Root>no session found flow_first_sanity_check: in <ethernet0/0>, out <N/A> packet dropped, first pak not syncPOLL_DROP_PAK: vlist 0x1c7d8d0, 0x1c7d8d0
Once the session check fails, a second sanity check is done that fails because the packet is a TCP packet, and not a SYN. This output is taken before the set zone untrust tcp-rst command is applied. When this command is set, the output of debug changes:
FIREWALL-A->get db str****** 2501576.0: <Untrust/ethernet0/0> packet received [40]****** ipid = 0(0000), @030f6490 packet passed sanity check. ethernet0/0:192.168.2.33/1->10.5.5.2/1,6<Root> no session foundflow_first_sanity_check: in <ethernet0/0>, out <N/A>**** jump to packet:10.5.5.2->192.168.2.33 skipping pre-frag no more encapping needed send out through normal path. flow_ip_send: 7353:10.5.5.2->192.168.2.33,6 => ethernet0/0(40) flag 0x0, vlan 0 no l2info for packet. no route for packet search route to (null, 0.0.0.0->192.168.2.33) in vr trust-vr for vsd-0/flag-2000/ifp-ethernet0/0 [ Dest] 7.route 192.168.2.33->192.168.5.1, to ethernet0/0 route to 192.168.5.1 arp entry found for 192.168.5.1 mac 0010db7f5e87 **** pak processing end. packet dropped, first pak not sync POLL_DROP_PAK: vlist 0x1c7d8d0, 0x1c7d8d0
In this debug output, notice that when the flow_first_sanity_check is performed, the next step is to jump to a new packet, this one from 10.5.5.2–192.168.2.33. This packet is actually a locally generated RSTspacket with the source IP address spoofed to be that of the original destination, 10.5.5.2. You can see this with snoop:
FIREWALL-A->snoop infoSnoop: ON Filters Defined: 1, Active Filters 1 Detail: OFF, Detail Display length: 1500 Snoop filter based on:id 1(on): IP dst-ip 192.168.2.33 dir(B) 2502577.0: ethernet0/0(o) len=60:0014f6e6d7c0->0010db7f5e87/080010.5.5.2 -> 192.168.2.33/6vhl=45, tos=00, id=59808, frag=0000, ttl=64 tlen=40 tcp:ports 1->1, seq=0, ack=0,flag=5004/RST
Here, notice the RST is being sent to the 192.168.2.33 address because TCP-RST is configured for the Untrust zone. If you prefer a silent drop of packets without an RST, do not include the set zone untrust tcp-rst command. Verify the Untrust zone settings using the get zone untrust command:
FIREWALL-A->get zone untrustZone name: Untrust, id: 1, type: Security(L3), vsys: Root, vrouter:trust-vr Intra-zone block: On, attrib: Shared, flag:0x6491TCP non SYN send reset: OnIP/TCP reassembly for ALG on traffic from/to this zone: No Asymmetric vpn: Disabled Policy Configurable: Yes PBR policy: None Interfaces bound:1. Designated ifp is ethernet0/0 interface ethernet0/0(0x2f7dcb4) IP classification disabled DHCP relay enabled
9.7. Detect and Drop Illegal Packets with Screens
Solution
Use screens to detect illegal packets:
FIREWALL-A->set zone untrust screen syn-finFIREWALL-A->set zone untrust screen syn-fragFIREWALL-A->set zone untrust screen fin-no-ackFIREWALL-A->set zone untrust screen icmp-idFIREWALL-A->set zone untrust screen tcp-no-flag
Discussion
Attackers often use illegal packets to attempt to identify an operating system they want to attack. Because these packets are illegal, different operating systems will respond to them in different ways, allowing a user to “fingerprint” the OS. Like all screens, when triggered, an alarm will be generated:
2007-9-12 12:39:38 system crit 00437 SYN and FIN bits! From 192.168.4.34:2280 to 10.5.5.2:80, proto TCP (zone Untrust, int ethernet0/0). Occurred 1 times. 2007-9-12 12:39:25 system crit 00413 No TCP flag! From 192.168.4.34:1730 to 10.5.5.2:80, proto TCP (zone Untrust, int ethernet0/0). Occurred 1 times. 2007-9-12 12:42:23 system crit 00412 SYN fragment! From 192.168.4.34:2211 to 10.5.5.2:80, proto TCP (zone Untrust, int ethernet0/0). Occurred 1 times.
As these packets are illegal, there is probably no good reason to allow them into the network.
9.8. Prevent IP Spoofing
Discussion
IP spoofing is a common method of bypassing firewall rules. By using a known permitted IP address as your source address, you can sometimes avoid firewall rule bases. Because ScreenOS uses a zone-based approach to rule base creation, spoofing is a greater challenge than with other firewall architectures, as the source interface is evaluated before a policy lookup is performed, and it would be unusual, for example, for an internal IP address to be allowed through the firewall’s external interface.
The IP spoof check in ScreenOS simply uses the routing table, and the concept of unicast reverse-path forwarding (RPF), to verify that the source IP of the traffic is arriving on the appropriate interface, and thus, whether it should be considered spoofed. Because the routing table is used for spoof protection, it is recommended that you use antispoofing only in statically routed scenarios, as with dynamic routing, a routing change could cause legitimate packets to be considered invalid. Consider the simple network in Figure 9-1.
In Figure 9-1, an attacker, knowing the internal IP address of the server he wants to attack, sends a packet with a spoofed IP address that appears to be on the internal LAN. In this case, the firewall’s route table has a route for 10.5.5.0/24 on the internal interface:
FIREWALL-A-> get route ip 10.5.5.0 Dest for 10.5.5.0 ------------------------------------------------------------------ -------------------- trust-vr : => 10.5.5.1/24 (id=8) via 0.0.0.0 (vr: trust-vr) Interface bgroup0 , metric 0
When IP spoofing protection is enabled on the Untrust zone, the firewall compares the route to the source IP address against the interface on which the packet was received. You can see this process in the output of debug flow basic:
FIREWALL-A->get db str****** 2657676.0: <Untrust/ethernet0/0> packet received [28]****** ipid = 0(0000), @030b8490 packet passed sanity check. ethernet0/0:10.5.5.3/1->10.5.5.2/53,17<Root> no session foundflow_first_sanity_check: in <ethernet0/0>, out <N/A> [ Dest] 8.route 10.5.5.3->0.0.0.0, to bgroup0 packet dropped, drop by spoofing check.
When the first sanity check is performed on the flow, the ingress interface, ethernet0/0, is compared against the route table’s route to the source IP. When this check is done, the firewall determines that the route back to the source is not the same as the ingress interface, and drops the packet.
This example assumes that the unicast RPF check for the packet will fail; however, that is not always the case. In some situations, the RPF check will succeed, but the IP address is still spoofed. This presents a challenge for connection-oriented protocols such as TCP. If the source IP is spoofed, the SYN-ACK packet from the server will never reach the attacker’s real IP address. In a situation where the attacker is merely trying to execute a DoS attack against the victim via a SYN flood, or a session table over-flow on the firewall, this may not matter. Half-open sessions will still result unless the set flow tcp-syn-check command is set and the three-way handshake is verified. To execute a more sophisticated attack, however, the full three-way handshake must be completed even though the source is spoofed. To accomplish this, typically the source route options in IP are used, and two types of source routes are defined: loose and strict. Loose source routes indicate the one or more hops a packet must traverse to reach its destination. Strict source routes specify all of the hops a packet must traverse to reach its destination. An attacker who spoofs the source IP of malicious traffic will often insert his own IP address as a loose hop in a source route of the packets he sends so that the reply will be routed back through him where he can intercept it. To combat this, use the ip-filter-src screen:
FIREWALL-A-> set zone untrust screen ip-filter-src
When this is applied, and packets arrive with the source route option set, an alarm is generated:
FIREWALL-A-> get alarm event Date Time Module Level Type Description 2007-9-12 11:58:33 system alert 00009 Source Route IP option! From 92.168.5.1:2465 to 10.5.5.2:0, proto TCP (zone Untrust, int ethernet0/0). Occurred 1 times.
When attempting to combat IP spoofing, it is recommended that you use a combination of the ip-spoof screen and the ip-filter-src screens, along with the command set flow tcp-syn-check.
9.9. Prevent DoS Attacks with Screens
Solution
Use screens to drop this traffic:
FIREWALL-A->set zone untrust screen landFIREWALL-A->set zone untrust screen tear-dropFIREWALL-A->set zone untrust screen winnuke
Discussion
ScreenOS protects against some well-known DoS attacks, which attack vulnerabilities in operating systems. The Land attack, for example, is a vulnerability common to many operating systems whereby a SYN packet sent to an open port with the source IP address equal to the destination IP address causes the machine to continuously send replies to itself until it exhausts its resources. Running snoop and debug when a Land attack is occurring shows the packet being dropped as hoped:
FIREWALL-A->get db str2684453.0: ethernet0/0(i) len=60:0010db7f5e87->0014f6e6d7c0/080010.5.5.2 -> 10.5.5.2/6vhl=45, tos=00,id=42347, frag=0000, ttl=63 tlen=40tcp:ports 80->80, seq=1133851487, ack=2019542178, flag=5002/SYN****** 2684453.0: <Untrust/ethernet0/0> packet received [40]******ipid = 42347(a56b), @03042490screen detection drop packet.
Notice the identical source and destination IP addresses, as well as the source and destination ports, and that the IP ID of the dropped packet is identical to the illegal packet. An alarm is generated:
FIREWALL-A-> get alarm event
Total event entries = 874
Date Time Module Level Type Description
2007-9-12 12:20:11 system alert 00010 Land attack! From 10.5.5.2:80 to
10.5.5.2:80, proto TCP (zone Untrust,
int ethernet0/0). Occurred 1 times.A Teardrop attack is an attack that utilizes overlapping IP fragments to crash a vulnerable machine. When such an attack is detected, alarms are generated:
FIREWALL-A-> get alarm eve Total event entries = 875 Date Time Module Level Type Description 2007-9-12 12:24:57 system emer 00006 Teardrop attack! From 192.168.2.33:1 to 10.5.5.2:80, proto TCP (zone Untrust, int ethernet0/0). Occurred 9 times.
Use the get zone <zonename> attack command to view the counters for these attacks:
FIREWALL-A->get zone untrust screen attack | include teardropTeardrop attack protection 44 FIREWALL-A->get zone untrust screen attack | include landLand attack protection 4
9.10. Use Screens to Control HTTP Content
Solution
Use the component block screens:
FIREWALL-A->set zone "Untrust" screen component-block zipFIREWALL-A->set zone "Untrust" screen component-block jarFIREWALL-A->set zone "Untrust" screen component-block exeFIREWALL-A->set zone "Untrust" screen component-block activex
Discussion
Much of the malicious content on the Internet is executed on unsuspecting hosts using malicious Java or ActiveX code. Other content can be downloaded onto an unsuspecting user’s machine as an executable or ZIPed file, and can exploit underlying vulnerabilities on the machine. To aid in preventing the unintended download of malware, ScreenOS allows you to block some of the more common content types which are used to spread malware. When component blocking is set, traffic entering the zone containing the file type is dropped, and the firewall rewrites the web page and provides a message to the user indicating that the traffic has been dropped. When malicious content is dropped, an alarm is generated:
FIREWALL-A-> get alarm event
Date Time Module Level Type Description
2007-09-03 13:24:55 system crit 00433 EXE file detected/blocked! From
63.229.53.23:80 to 192.168.1.7:1631,
proto TCP (zone Untrust, int
ethernet3). Occurred 1 times.From the user’s perspective, after attempting to download the .exe file, the firewall presents the page to the user, as you can see in Figure 9-2.
HTTP component blocking in ScreenOS provides a simple method of restricting access to potentially harmful content. This simplicity has a price, however, and that price comes in the form of a performance hit, and a lack of granularity. The performance hit is particularly acute on ASIC-based platforms such as the ISG Series. Unless there are no performance concerns and the all-or-none method of dropping traffic is acceptable, this functionality may be better suited to an external system, or to other features such as URL filtering or IDP.