[6865] in bugtraq
Re: Problem with ascend pipeline routers.
daemon@ATHENA.MIT.EDU (James Bass)
Fri May 29 15:22:54 1998
Date: Fri, 29 May 1998 12:33:59 -0500
Reply-To: James Bass <jamesb@DBN.NET>
From: James Bass <jamesb@DBN.NET>
To: BUGTRAQ@NETSPACE.ORG
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:jshaw@INSYNC.NET]
> Sent: Thursday, May 28, 1998 3:54 PM
> To: BUGTRAQ@NETSPACE.ORG
> 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 <support@ascend.com>
> > To: eric@caffrey.net
> > 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
> > support@ascend.com
> > http://www.ascend.com/service
>
> I've forwarded this to the ascend users group (ascend-users@bungi.com)
> so
> we can get Kevin Smith's (kevin@ascend.com) and Matt Holdrege's
> (matt@ascend.com) 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 - jshaw@insync.net
> NetAdmin - Insync Internet Services
