Re: Cisco says attacks are due to operational practices

["John M. Brown" <jmbrown () ihighway net>]

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
> --**--**--**--**--**--**--**--**--**--**--**--