Re: Problem with ascend pipeline routers.

[jamesb () DBN NET (James Bass)]

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