[27277] in North American Network Operators' Group
Re: Cisco says attacks are due to operational practices
daemon@ATHENA.MIT.EDU (John M. Brown)
Thu Feb 10 21:29:10 2000
Message-ID: <20000210194049.G20594@abq-mail-01.ihighway.net>
Date: Thu, 10 Feb 2000 19:40:49 -0700
From: "John M. Brown" <jmbrown@ihighway.net>
To: Chris Cappuccio <chris@dqc.org>,
"John M. Brown" <jmbrown@ihighway.net>
Cc: nanog@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.BSO.4.21.0002101812130.2897-100000@dqc.org>; from Chris Cappuccio on Thu, Feb 10, 2000 at 06:13:56PM -0800
Errors-To: owner-nanog-outgoing@merit.edu
I am not doing this on backbone routers. I am doing this on edge routers. Outside
world, nor our customers really need to goto say port 19 (chargen), or say 7 (echo)
etc.
And, yes there is disclosure to our customers on this.
Again, we don't do this on our core, we do it on our EDGE, at no point did I
say core.
Filtering against spoofed IP is a good thing
On Thu, Feb 10, 2000 at 06:13:56PM -0800, Chris Cappuccio wrote:
> Filtering incoming our outgoing ports for anybody's network but your own (not
> your customer's) is wrong. You know specifically what apps you are running.
> How can you know what your customer is running or what they want to do ?
>
> If the customer is aware this is happening or even requests this type of
> firewall service, that's great. But to filter ports on backbone routers is
> stupid.
>
> On Thu, 10 Feb 2000, John M. Brown wrote:
>
> |
> | We have always built martian filters on our edge routers. In addition we
> | built specific filters for ports that are not used, or are bad on the net.
> |
> | No matter what the customers router is doing, ours will drop 1918 and other
> | IP blocks, and ports.
> |
> | This can be automated and can be deployed over a reasonable period of time.
> | Most MAJOR backbone providers do not do this, wish they would
> |
> | jmbrown
> |
> |
> | On Thu, Feb 10, 2000 at 06:48:06PM -0700, Tom Beeson wrote:
> | >
> | > At 02:29 PM 2/10/00 -0800, Sean Donelan wrote:
> | >
> | > >In an InteractiveWeek article the head of Cisco's security products group
> | > >says the attacks are an operational problem not a technical problem.
> | > >
> | > > >Routers from Cisco and other vendors have the ability to detect the
> | > > signature
> | > > >patterns of a denial-of-service attack, and the routers can filter out that
> | > > >traffic, Farnsworth said.
> | > > >
> | > > >"The router knows which sources are legitimate or not and drops on the floor
> | > > >anything suspicious," Farnsworth said. "Generally speaking, ingress
> | > > filtering
> | > > >and committed rates are effective in terms of preventing [malicious] traffic
> | > > >from ever showing up, or filtering it to a reasonable rate."
> | >
> | > I would agree with Farnsworth. Cisco routers do have some of the richest
> | > filtering mechanisms available. Though the configuration is best done at
> | > the edge routers (not on any core backbone). Considering the huge number
> | > of end sites out there, this is labor intensive. If you were a medium or
> | > large ISP that had 250+ end sites behind you, then you would have to go out
> | > and reprogram over 250+ routers. Placing the same changes on the core
> | > routers is impractical since it would be very CPU and Memory intensive and
> | > just as big a pain to administer. We made a decision over a year ago to
> | > start making changes on as many of our customer end sites as possible.
> | >
> | > We wrote an in-house perl script to take a Cisco router configuration and
> | > build inbound and outbound filters. These filters are then applied to the
> | > serial interface that connects to our network and toward the Internet. The
> | > inbound filter prevents outsiders from spoofing a LAN IP address aimed at
> | > that specific site. The outbound filter prevents someone on the LAN from
> | > sending spoofed packets (bogus source IP addresses) from getting to the
> | > Internet. Our script also adds the "no IP directed-broadcast", "no service
> | > udp-small-servers", and "no service tcp-small-servers" commands. We also
> | > add restricted telnet access and other security related commands. The
> | > suggested modifications are written to a text file and can be further
> | > edited and TFTP'd to the router at the discretion of the engineer.
> | >
> | > We routinely manage a large majority our customer's routers. For our
> | > customers who manage their own routers, we urge them to add these filets
> | > and work to make them aware of any security changes they should
> | > make. Education of the customer becomes key to stopping spoofed packets
> | > from leaving your network. :-)
> | >
> | > We turned on logging on a few sites where we suspected some suspicious
> | > activity and actually logged a number of spoofed packets that were caught
> | > in the anti-spoofing filters. The bad news is that we have not caught the
> | > actual persons sending out the spoofed packets. We suspect that these guys
> | > may have moved on somewhere else. If you are willing to commit the
> | > resources and time setting anti-spoofing filters on all your end site
> | > routers, it is a very worthwhile thing.
> | >
> | >
> | > -- Tom Beeson
> | >
> | > My 2 cents worth. Views are my own and not necessarily that of the company
> | > for which I work.
> | >
> | > --**--**--**--**--**--**--**--**--**--**--**--
> | > Tom Beeson Oso Grande Technologies
> | > Network Engineer A New Mexico Technet Co.
> | > (505) 345-1748
> | > noc@nm.net
> | > --**--**--**--**--**--**--**--**--**--**--**--
> | >
> | >
> |
> |
>
> ---
> Gates' Law: Every 18 months, the speed of software halves.
>
