nanog mailing list archives
Re: source filtering
From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Wed, 13 Jan 1999 12:36:58 +0300 (MSK)
Hi. Yep, you are right, you can protect yourself from smurf with a little help of your upstream provider (CAR on upstream link and autho-installed filter working by netflow analyser). What you can't do and what's much more dangerous is netfloods by IP fragments with random -generated SRC addresses and a lot of small packets - they flood WFQ queueries, overrun netflow accounting, waist CPU poewr of the routers and (amazing) they often can't be filter out at all (it's true for the CISCO in some cases). Again, the only _SOLID_ solution for the future internet is strict SRC filtering over all ISP. I note - ALL, may be it should be some kind of _open policy_, may be something else. Internet have not other choise to survive. On Tue, 12 Jan 1999 prue () ISI EDU wrote:
Date: Tue, 12 Jan 1999 15:54:37 -0800 From: prue () ISI EDU To: nanog () merit edu Cc: Prue () ISI EDU Subject: Re: source filtering On Tue, Jan 12, 1999 at 01:11:09PM -0500, Steve Gibbard wrote: ==>On Tue, 12 Jan 1999 danderson () lycos com wrote: ==> ==>> I'm not sure what the big issue here is with the smurf attacks. If you set ==>> up some kind of access list that disables incoming icmp traffic, then turn ==> ==>That breaks path MTU discovery (see RFC 1435 for more info on that), among ==>other things. What I have done is write a C program which looks at netflow records as they come in,(close to real time). It checks the source port on the Cisco, the flow record identifies, and compares the source address to a list of acceptable source addresses for validity. I give the program a list of permit and deny like records with IP address and mask along with the ordinal port number. Any that are not legit get printed out. You can then beat on your customer until they clean up their act. If they don't stop right away you can always put in a filter on the interface til they do. We have pretty strong contract verbage which permits us to cut people off if their connection is being used for predatory activity. We haven't had to resort to that yet but being able to say "Fix it or I turn your connection down til you do" is very effective. The nice thing is that it doesn't slow the router down at all, as long as you are doing netflow anyhow. I modified a copy of fdget which is Ciscos netflow demonstration software they have available via ftp. That made the programming task easy for a non programming type like me. Walt Prue
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Current thread:
- Re: source filtering, (continued)
- Re: source filtering Alex Bligh (Jan 12)
- Re: source filtering Dan Hollis (Jan 12)
- Re: source filtering Craig A. Huegen (Jan 12)
- Re: source filtering Craig A. Huegen (Jan 12)
- Re: source filtering Dan Hollis (Jan 12)
- Re: source filtering Daniel Senie (Jan 12)
- Re: source filtering Dalvenjah FoxFire (Jan 12)
- Re: source filtering Phillip Vandry (Jan 12)
- Re: source filtering Alex P. Rudnev (Jan 13)
- Message not available
- Re: source filtering Tony Tauber (Jan 13)
- Message not available
- Re: source filtering Jay R. Ashworth (Jan 16)
- Message not available
- Re: source filtering Tony Tauber (Jan 17)