Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) GRF filter to block Smurf attacks
At 12:52 PM 9/23/98 -0400, Jeremy T. Bouse wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
> Out of curiousity has anyone with a GRF designed a filter config
>to stop smurf (broadcast) attacks? A recent "irc packet warrior" decided
>to smurf one of our dial-up boxes and lit our hubs in the NOC up like a
>burning X-mas tree... current fix was to block all ICMP traffic from the
>class B block the broadcast packets were coming as. Not the best fix but
>it stopped the X-mas tree affect on the hubs. We're looking at a more
>permanent solution that can keep this frmo happening again.
Sorry this took so long, it got lost in my inbox...
Configuring Anti-Spoofing Filters on the GRF
Table of Contents
Abstract
Definition
Requirements
Steps
Common Mistakes to Avoid
Abstract
This document provides step-by-step instructions in a tutorial format for
creating Anti-Spoofing filters on the GRF. This will help protect your
network from Smurf attacks.
Definition
Spoofing is the practice of sending IP packets with a forged Source
Address, in other words, sending packets that claim to come from a host
other than the sender.
Requirements
There are two kinds of Spoofing that you probably want to protect against;
each of these cases requires a separate filter on the GRF:
· Preventing external hosts from forging source IP addresses that belong to
your own customers, and
· Preventing your customers from forging someone else's IP addresses.
Steps
1. The first task in setting up Anti-Spoofing filters is to have a complete
understanding of your network's topology and address assignments. For our
examples, let's assume that your network looks like the above diagram, and
has been assigned address ranges of 205.199.192/18 and 209.155.240/20
2. Next, set up a filter to prevent outsiders from pretending to be one of
your customers. You want to ensure that no packets arriving from the
Internet claim to have a source IP address that belongs to your network;
all other packets arriving from the Internet should be allowed. Place the
following text in your GRF's /etc/filterd.conf file.
filter no_spoof_in {
implicit permit;
deny {
from 205.199.192.0 0.0.63.255;
from 209.155.240.0 0.0.15.255;
};
};
media hssi 3 {
bind no_spoof_in {
vlif 0..127;
direction in;
action filter;
};
};
The first statement defines the filter. The filter specifies a default
permission which will be applied if none of the ensuing rules are invoked,
followed by more specific permission rules. In our case, we have only one
rule: if the packet's source IP address matches either of the address
expressions, it will be denied, or dropped, by the GRF rather than being
forwarded on to its destination.
The second statement attaches the filter to a particular interface on the
router. In our example, the connection to the rest of the Internet is
assumed to be a Frame Relay connection on the HSSI media card in slot 3 of
the GRF. The vlif clause refers to which logical interfaces on the media
card are affected by the filter; in this case, we have specified 0 through
127, which means all of the Frame Relay PVCs on port A of the HSSI card.
3. Although the task of preventing your own customers from forging the
source IP address in their own packets is a little bit more complex, it is
well worth the effort. Preventing your customers from sending forged
packets in the first place is significantly easier than having to track
down in real time the source of particular packets when your upstream
provider reports that a Smurf attack is coming from your network.
Let's assume that none of the Access Devices are running any sort of
dynamic routing protocol, and that all packets received from a Customer's
host(s) are forwarded to the GRF using a default route (or are routed
directly to another Customer's connection on the same Access Device). So,
the GRF has to accept packets from all of the Access Devices' Address
Pools, and must forward packets to all pools, too.
Add the text on the following page to your GRF's /etc/filterd.conf file:
filter no_spoof_out {
implicit deny;
deny {
from 209.155.252.0 0.0.3.255;
to 209.155.252.0 0.0.3.255;
};
permit {
from 209.155.252.0 0.0.3.255;
};
deny {
from 209.155.248.0 0.0.3.255;
to 209.155.248.0 0.0.3.255;
};
permit {
from 209.155.248.0 0.0.3.255;
};
deny {
from 205.199.196.0 0.0.3.255;
to 205.199.196.0 0.0.3.255;
};
permit {
from 205.199.196.0 0.0.3.255;
};
deny {
from 209.155.240.0 0.0.0.255;
to 209.155.240.0 0.0.0.255;
};
permit {
from 209.155.240.0 0.0.0.255;
};
};
media ether 1 {
bind no_spoof_out {
vlif 0;
direction in;
action filter;
};
};
Just as with the no_spoof_in filter, this one defines a default
permission, but this time the default is to deny the packets' entry into
the GRF. Then, there are three pairs of rule, one for each Access Device's
Address Pool. In each pair, the first rule prevents a Customer attached to
the Access Device from forging a source address that "belongs" to another
Access Device on packets destined to that other Access Device; the second
rule in each pair permits all other packets to be routed normally. The
final pair of rules in this filter allows the other devices on the local
Ethernet segment to access the network while preventing forging of their
addresses by Customers.
Note that this filter does not prevent Customer A from forging a source
address belonging to Customer B if both Customers are attached to the same
Access Device. This type of intra-Customer spoofing cannot be performed by
the GRF, since such packets would never be sent to the GRF in the first
place. Also, this filter does not prevent Customer A from forging a
Customer B source address if the packet needs to be routed through either
of the HSSI links. Only the Access Devices can determine if the packet's
source address belong to them; the GRF can only determine whether the
source address should be arriving via the Ethernet interface.
4. In the real world, the Access Devices would most likely be running some
sort of dynamic routing protocol, such as RIP or OSPF, and thus would be
able to route packets from one Access Device to the other directly, without
using the GRF. In this situation, the GRF cannot filter on packets between
customers on different Access Devices, since the packets will not even be
sent to the GRF. So, the following, much simpler filter will accomplish
everything that the GRF can be expected to do. This filter can be used
instead of the filter defined in Step 3.
filter no_spoof_out_2 {
implicit deny;
permit {
from 209.155.248.0 0.0.7.255;
from 205.199.196.0 0.0.3.255;
from 209.155.240.0 0.0.0.255;
};
};
media ether_1 {
bind no_spoof_out_2 {
vlif 0;
direction in;
action filter;
};
};
Note that in this case the two address ranges 209.155.248/22 and
209.155.252/22 have been combined into a single from clause with a shorter
network mask! You should always try to keep your filters as short as
possible in order to minimize the performance impact on the GRF.
5. One more filter is required on the GRF to complete your anti-Spoofing
efforts. This last filter can be added to your /etc/filterd.conf file to
ensure that no one in the rest of your network can forge source addresses
that belong to your local Access Devices.
filter no_spoof_other {
implicit deny;
deny {
from 209.155.248.0 0.0.7.255;
from 209.199.196.0 0.0.3.255;
from 209.155.240.0 0.0.0.255;
};
permit {
from 205.199.192.0 0.0.63.255;
from 209.155.240.0 0.0.15.255;
};
};
media hssi 3 {
bind no_spoof_other {
vlif 128..255;
direction in;
action filter;
};
};
Common Mistakes to Avoid
The permission rules in a filter are evaluated in the order that they are
listed in the /etc/filterd.conf file, and packets are permitted or denied
based on the first rule that the packet matches. In the final example, the
first rule denies any packets with a source address that belongs to your
local Ethernet address, while the second rule permits any packets that
belong to your assigned address space. If these rules were listed in the
opposite order, the more specific rule would never be invoked because any
packet that would match the more specific rule and be denied would already
have matched the preceding less specific rule and thus it would already
have been permitted!
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>