source filtering

Jared,

jared@puck.nether.net said:

  This does not mean you can't filter on your fastether, ether, fddi,
etc.. that goes to customer aggregation boxes,

(i.e. on the core router on ingress core). Yes, but (it would seem
in practice) not if your network access LAN is multihomed and non-trivial
in topology.

Also causes problems if you use FR or ATM as access concentrators
directly into the core (oh if only you could stick this command on
a multipoint cloud and CEF worked properly).

My point was if one shipped CPE routers out, the responsible ISP
can ship them with "no ip directed broadcast" PLUS "ip verify unicast
reverse-path" on the CPE LAN interface, and ensure customers are
neither third-party reflectors nor perpetrators. Then use CEF to
rate-limit ICMP at the borders (which nearly works but not quite) and
you've mitigated the customers-as-victims problem too.

Is UDP smurf much in evidence? (send a UDP packet to the broadcast address
on the echo server port and you'll either get ICMP port unreachables
back or UDP echos). The reason I ask is that edge ICMP rate
limiting won't help UDP.

==>Is UDP smurf much in evidence? (send a UDP packet to the broadcast address
==>on the echo server port and you'll either get ICMP port unreachables
==>back or UDP echos). The reason I ask is that edge ICMP rate
==>limiting won't help UDP.

People are still preferring ICMP smurfs as the reflection is usually
greater.

With that said, you can use a line like the following to filter UDP
echo smurfs at the network border; it won't affect other UDP traffic.

access-list 101 permit udp any eq 7 any

/cah

Yes. About 50% of the smurf attacks we get are UDP.

-Dan

On Tue, Jan 12, 1999 at 06:25:47PM +0000, Alex Bligh put this into my mailbox:

Is UDP smurf much in evidence? (send a UDP packet to the broadcast address
on the echo server port and you'll either get ICMP port unreachables
back or UDP echos). The reason I ask is that edge ICMP rate
limiting won't help UDP.

Supposedly UDP smurf (fraggle) is becoming more popular. I haven't
seen it myself.

The only type of UDP attack I've seen has been where a user breaks
into machine on high bandwidth, fails to get root, and runs a program
that sends large amounts of huge UDP packets to a destination host.
This makes tracing the problem loads easier, and your upstream can
block out the single host.

-dalvenjah

"Craig A. Huegen" wrote:

==>Is UDP smurf much in evidence? (send a UDP packet to the broadcast address
==>on the echo server port and you'll either get ICMP port unreachables
==>back or UDP echos). The reason I ask is that edge ICMP rate
==>limiting won't help UDP.

People are still preferring ICMP smurfs as the reflection is usually
greater.

With that said, you can use a line like the following to filter UDP
echo smurfs at the network border; it won't affect other UDP traffic.

access-list 101 permit udp any eq 7 any

A side effect of the above filter is that it'll interfere with some web
caches. Now mind you I'm not sure that's a bad thing or a good thing,
it's just how it is. Whomever came up with using the UDP echo port as
part of a web cache's operation must have had no ops experience on the
Internet. The web cache packets are recognizable by having a source port
of 3130 and destination port of 7.

Since I care more about preventing attacks than I do about web caches, I
allow these to be blocked.

Dan

The last UDP smurf we got was udp port 23. Strange but true.

-Dan

My data against IRC servers shows otherwise. I see
a *great* number of UDP floods -- but they're not reflected
attacks. They typically consist of a well-connected but
poorly-secured machine at a university.

/cah