Re: Cisco says attacks are due to operational practices

[John M. Brown]

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