You can always set up secure-access on it (if you want to waste a few bucks), or just set up a few filters so that only certain boxes (or only the LAN) have access to telnet to the box. There is a FAQ that addresses that issue at: http://www.ascend.com/faqs/400/122.html > -----Original Message----- > From: Joe Shaw [SMTP:jshawat_private] > Sent: Thursday, May 28, 1998 3:54 PM > To: BUGTRAQat_private > Subject: Re: Problem with ascend pipeline routers. > > On Wed, 27 May 1998, Eric Thacker wrote: > > > Date: Tue, 26 May 1998 14:19:30 -0700 > > From: support <supportat_private> > > To: ericat_private > > Subject: RE: Ticket #238563 > > > > Eric: > > > > The pipeline has no way of telling what is a legit telnet and what > is > > not and because the box is meant to be accessed this way (both > locally > > and remotely), a firewall is the best way to restrict telnet access. > > > > -- > > Ascend Communications, Inc Service & Support > > supportat_private > > http://www.ascend.com/service > > I've forwarded this to the ascend users group (ascend-usersat_private) > so > we can get Kevin Smith's (kevinat_private) and Matt Holdrege's > (mattat_private) opinion on this. > > I have my own opinions on the problem. The Pipeline family has always > been a very basic, barebones line of routers with a somewhat limited > set > of functions. They'll do NAT, RIP, etc. but all of them only allow > you > two telnet sessions into the router and only one diagnostics session. > This was done to limit the resources that would be consumed so ram/cpu > wouldn't be burderend with tons of telnet sessions and/or diagnostic > sessions which can kill it's bigger brother the MAX, just like doing > debug all on a cisco will hose it. > > But regardless, even if there was an idle timer on the authentication > mechanism, there are still a few problems. One problem is that even > with a login timeout, you're going to have two telnet sessions max, > which > is a limit placed most likely by the resources mentioned earlier. > So, > you can just keep opening telnet sessions as soon as the others die > and > see if you can keep telnet access locked up. Also, as of the 5.0A > versions of code (and possibly earlier) the ascend doesn't log telnet > connections to the syslog facility. My maxen don't do it, and the > pipeline logs I've looked at don't do it. They do log incoming calls, > call up, call down, and various other events, but not telnet access. > So, tracking down who's doing this would involve a sniffer, which > might > not be a readily available tool to most people with pipelines as > routers. > > You're right though, the best way to handle the problem is by > firewalling > or filtering out telnet access. Guess this is a good selling point > for > their Secure Access Firewall option. > > Also, I was able to knock out 3 of my Ascend Maxen by repetedly > telneting > to them. Software version was 5.0Ap51, file ti.m40. On a heavily > loaded > max, I opened two successful simultaneous telnets and it died on the > third, while another max died at four. I'm going to investigate > further, > and I have no info on the 6.0.X versions of max code yet. > > Joe Shaw - jshawat_private > NetAdmin - Insync Internet Services
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:55:22 PDT