|
Attack Guards
Feb 08,2010 00:00
by
alperen
Attack GuardsThe PIX Firewall offers a family of features to defend the device and protected networks from attack. The PIX application-inspection capabilities and IDS features work together to provide services similar to those covered in Chapters 6 (IDS) and 7 (CBAC). Attack guards refer to the PIX Firewall application-layer inspection capabilities that have been programmed to prevent specific kinds of common attacks. This section looks at the following attack guards.
DNS ControlTo defend against the growing threat of DNS attacks, Cisco introduced an always-on feature called DNS Guard. Because DNS Guard can neither be turned off nor configured, DNS has no fixup protocol command. Generic UDP handling of DNS queries leaves connections open longer than is prudent. Instead, the PIX Firewall identifies each outbound DNS resolve request, and then tears down the connection as soon as a single reply is received. While a host might query several servers for a response in case the first server is down or congested, only the first answer to that request is allowed. Additional responses are dropped. This prevents a hacker from following a legitimate DNS reply with a modified version directing traffic to another site. PIX Firewall version 6.2 supports NAT and PAT of DNS messages originating from both inside (more secure) and outside (less secure) interfaces. The embedded addresses in both the query and reply message are now translated, and names resolution works as expected. Flood DefenderThe Flood Defender feature is used to reclaim PIX Firewall resources if the user authentication subsystem runs out of resources. If an inbound or an outbound authentication connection is being attacked or overused, the PIX Firewall actively reclaims TCP user resources. The feature is enabled by default. The Flood Defender feature is enabled/disabled with the floodguard command using the following syntax:
The show floodguard, show running-config, and write terminal commands will all display the flood-defender status. As resource depletion gets more serious, the PIX Firewall starts reclaiming TCP user resources in the following order, depending on urgency of the shortage:
FragGuard and Virtual ReassemblyFragGuard and Virtual Reassembly are default features that provide IP fragment protection for traffic passing through the PIX Firewall. FragGuard fully reassembles all ICMP error messages and performs virtual reassembly of all other IP fragments. Syslog messages are generated by any fragment overlapping and small fragment offset anomalies, common to variations of the teardrop attack. Teardrop attacks work by sending deliberately constructed IP fragments, which are reassembled into an invalid UDP datagram. Overlapping offsets work by causing additional fragments to overwrite data in the middle of the UDP header. This is contained in the first fragment in such a way that the datagrams are left incomplete. The configuration mode fragment command provides additional management of packet fragmentation and improves compatibility with NFS. The syntax is as follows:
The clear fragment command clears the fragment databases and resets all defaults. Any fragments waiting for reassembly are discarded. The show fragment [int_name] command displays the settings and statistics of the fragment database for the specified interface. If int_name isn’t specified, the command applies to all interfaces. The following output shows a sample with the default settings: Pix(config)# show fragment The PIX Firewall, by default, accepts up to 24 fragments to reassemble a full IP packet. To increase network security, consistent with the security policy, configure the firewall not to accept fragmented packets with the Fragment Size 1 command option. Using a limit of one means only whole packets will be accepted. The following output shows increasing the fragment size and timeout on all interfaces, plus eliminating fragments on the less-secure interfaces. Pix(config)# fragment size 500 The sysopt security fragguard CommandThe sysopt commands are used to modify about a dozen PIX Firewall system options. Our interest at this point is specifically the sysopt security fragguard command. Although it’s disabled by default, once this feature is enabled, it enforces two addition security checks beyond those recommended by RFC 1858 (IP fragment–style attacks, such as teardrop, land, and so forth).
The feature operates on all PIX Firewall interfaces and can’t be selectively enabled or disabled by interface. No Security FragGuard options exist. The syntax is as follows:
The clear sysopt command resets all sysopt commands to default settings.
TCP InterceptThe TCP Intercept feature protects inside systems (servers) from a common type of denial of service (DoS) attack, which is perpetrated by flooding an interface with TCP SYN packets that create half-open TCP (embryonic) connections. The feature is enabled by setting the maximum Embryonic (em_limit) Connections option on the nat and static commands. Both features were covered in Chapter 19. The syntax is the following:
Once the embryonic connection limit is reached, and until the embryonic connection count falls below this threshold, the firewall intercepts additional SYN packets. The PIX Firewall works as a proxy and responds on behalf of the server, with a SYN/ACK reply turning the session over to the server if it’s successfully established. Unicast Reverse Path ForwardingSpoofing IP source addresses in the IP protocol is a common tool for evil doers to attempt to conceal their identities. Unicast Reverse Path Forwarding (Unicast RPF), or reverse route lookup, provides inbound and outbound filtering to help prevent IP address spoofing. The feature verifies that source addresses of inbound packets are verifiable by routes in the local PIX routing table. Realistically, the ip verify reverse-path interface command is most useful in reducing the chances of internal hosts becoming parties to an attack and outsiders spoofing a trusted inside address. The syntax is
Because Unicast RPF is limited to verifying addresses against those in the local route table, the following two conditions are critical:
The following example defines IP addresses for three interfaces, creates a default route to the outside, defines the four networks expected on the other side of an inside router, and assumes all DMZ hosts will be connected locally to the 192.168.128.0 network. Pix(config)# ip address outside 1.1.1.1 255.255.255.0 The ip verify reverse-path interface outside command ensures no packets arrive from the outside with sources addresses defined for the inside or DMZ networks. The ip verify reverse-path interface inside command prevents any packets coming from the inside with source addresses that aren’t defined to that interface. The final command limits packets coming in from the DMZ to source addresses in the 192.168.128.0 network. The following output shows using the show ip verify command to confirm configuration and the show ip verify statistics command to show activity. Pix(config)# show ip verify ActiveX Blocking, Java Filtering, and URL FilteringThese three features were covered in Chapter 19 as content filtering using the filter command. All three are made possible because of the fixup protocol http [port] command. They are included here as attack guards.
|