Specifications

Page 112 /148
3.5.2.2 Filtering Application: Tracing DOS Attacks
Denial-of-Service (DOS) attacks are a large concern of ISPs because an attack
results in slower network performance, potentially for a large number of
customers. A frequently used DOS approach, known as a Smurf Attack, is to
spoof the source address of the targeted victim in a series of packets that are
sent to a broadcast domain at a proxy site. Each packet requests that all hosts in
the broadcast domain send a ping response to the (spoofed) source address.
Thus, the victim’ s node (typically a host) is flooded with ping responses,
consuming access routing resources and preventing the servicing of other traffic
through the access link. As discussed above, many of these DOS attacks can be
prevented by implementing source address verification at the network ingress
point. However, in order to use source address verification, the range of
addresses at the other end of the ingress link must be known. In the case of
peering connections, all of the source addresses are not known. Hence, a DOS
attack could still originate from a peering connection. For such cases, the Internet
Processor II offers the ability to trace any DOS attack back to the point at which it
entered the network. Once an attack is identified, a filter with the “log” function
enabled can be used to notify higher layers of the system of receipt of the packet
and the interface through which it arrived. Once the incoming port is identified,
the same filter is applied to the upstream router on the other end of the incoming
link. The process is repeated all the way back to the point at which the attack
entered the network. If the ingress point is a peering connection, a filter is applied
to prevent the attack from entering the network and the adjacent ISP is notified
that an attack is coming from its domain. Tracing DOS attacks is a fundamental
tool for ISPs and the Internet Processor provides such a tool in the form of rich
filtering functionality and ASIC-based performance.
3.5.2.3 Filtering Application: Outsourced CPE Filter
The Internet Processor II filtering functionality gives providers the ability to offer
outsourced filtering services to subscribers. Configuration of access lists to
implement filters can be difficult for customers to maintain. Additionally, dropping
traffic destined for the subscriber at the CPE is inefficient because it still takes up
capacity on the link. If traffic going to the subscriber is to be filtered, it is
preferable to filter it on the provider side.For example, with the Internet Processor
II, providers can configure an outsourced filter for a subscriber that allows HTTP
traffic in, but filters other traffic (eg TELNET, rsh) for security. Additionally, the
filter can be used to restrict access to the internal web server (ie intranet) to
authorized sources. It should be noted that the Internet Pr ocessor II provides
filtering functionality only and is not intended to serve as a full-fledged firewall (a
la Checkpoint) with AAA functionality.
3.5.2.4 Firewall Filter Components
In a firewall filter, you define one or more terms that specify the filtering criteria
and the action to take if a match occurs. Each term consists of two components:
§ Match conditions—Values or fields that the packet must contain. You
can define various match conditions, including the IP source address
field, the IP destination address field, the TCP or UDP source port field,
the IP protocol field, the ICMP packet type, IP options, TCP flags,
incoming logical or physical interface, and outgoing logical or physical
interface.
§ Action—Specifies what to do if a packet matches the match conditions.
Possible actions are to accept, discard, or reject a packet, or to take no
action. In addition, statistical information can be recorded for a packet: it
can be counted, logged, or sampled.
The ordering of the terms within a firewall filter is significant. Packets are tested
against each term in the order they are listed in the configuration. When the first
matching conditions are found, the action associated with that term is applied to
the packet. If, after all terms are evaluated, a packet matches no terms in a filter,
the packet is silently discarded.
3.5.3 Routing Engine Firewall
JUNOS supports a Routing Engine Firewall that allows you to filter packets based
on their contents and to perform an action on packets that match the filter. The
firewall can be used to control access to the routing engine by restricting the
packets that can pass from the physical interfaces to the routing engine. Such