I'm interested in what providers actually do source filtering of their customers. Including: 1) Using access-lists to filter your customers 2) Using the "ip verifiy unicast reverse-path" Cisco feature (it's in 11.1CC images when you use CEF, so I don't get a flood of e-mails) 3) Using other router vendors and features you have to filter source addresses. I'd like to summarize this all and start a quest to fix providers that don't source filter (as people quest against spam, and against smurfable network blocks). - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
2) Using the "ip verifiy unicast reverse-path" Cisco feature (it's in 11.1CC images when you use CEF, so I don't get a flood of e-mails)
I'm sure far more people would source filter if Cisco put this in CPE routers. -- Alex Bligh GX Networks (formerly Xara Networks)
On Tue, Jan 12, 1999 at 05:51:36PM +0000, Alex Bligh wrote:
2) Using the "ip verifiy unicast reverse-path" Cisco feature (it's in 11.1CC images when you use CEF, so I don't get a flood of e-mails)
I'm sure far more people would source filter if Cisco put this in CPE routers.
This does not mean you can't filter on your fastether, ether, fddi, etc.. that goes to customer aggregation boxes, or on the T1 where that connectivity hits your core backbone node, (I understand there are cases where this would not work, for some larger customers perhaps), but for most cases, this would be possible. If i have network topology that provides the following scenario: upstream | +----------+ | core rtr |--- N x backbone link(s) +----------+ \ \ +------------+ -| access lan | +------------+ Where access lan is any number of customer aggregation boxes, such as 36xx w/ t1 intfs, (dial) access boxes, etc, you can source filter that lan at that point instead of the edge. If you manage lans similar to this, you shouldn't allow your dial customers to spoof and start these attacks. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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. -- Alex Bligh GX Networks (formerly Xara Networks)
On Tue, Jan 12, 1999 at 06:25:47PM +0000, Alex Bligh 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 /cah
"Craig A. Huegen" wrote:
On Tue, Jan 12, 1999 at 06:25:47PM +0000, Alex Bligh 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 -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
On Tue, 12 Jan 1999, Craig A. Huegen wrote:
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
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 On Tue, Jan 12, 1999 at 11:02:44AM -0800, Dan Hollis wrote: ==>On Tue, 12 Jan 1999, Alex Bligh wrote: ==>> Is UDP smurf much in evidence? ==> ==>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 -- Dalvenjah FoxFire (aka Sven Nielsen) The name's Bean....Mr. Bean. Founder, the DALnet IRC Network e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Tue, Jan 12, 1999 at 05:51:36PM +0000, Alex Bligh wrote:
2) Using the "ip verifiy unicast reverse-path" Cisco feature (it's in 11.1CC images when you use CEF, so I don't get a flood of e-mails)
I'm sure far more people would source filter if Cisco put this in CPE routers.
This does not mean you can't filter on your fastether, ether, fddi, etc.. that goes to customer aggregation boxes, or on the T1 where that connectivity hits your core backbone node, (I understand there are cases where this would not work, for some larger customers perhaps), but for most cases, this would be possible.
The problem with filtering "far" from your edge is that if you have customers that need to be excepted, you need to except the whole bunch of them that goes through that aggregated interface. Any multihomed customer needs to be excepted if there's any chance they're going to do asymetric routing -- so long as they commit to filtering at their edge. You *need* to filter close to your edge. -Phil
participants (7)
-
Alex Bligh -
Craig A. Huegen -
Dalvenjah FoxFire -
Dan Hollis -
Daniel Senie -
Jared Mauch -
Phillip Vandry