Re: WebRamp M3 Perceived Bug

[stanley () PEAK ORG (John Stanley)]

Regarding the subject, am I to assume that since this is only a
"perceived" bug, your supervisor of customer service was fibbing to me
when he admitted on the phone that this was, indeed, a problem that needed
to be fixed? He hasn't called me back like he promised he was going to,
nor has he sent me email like he promised he would. Since he's gone mute,
are you the official Rampnet spokesman now?

On Wed, 3 Feb 1999, Robert Ward wrote:

> 1)  The perceived problem is that upon manualling disabling the diversion of
> incoming telnet requests to the webramp, and not setting up a Visible
> Computer, or telnet Local Server, telnet traffic continues to divert to the
> Webramp.

This is not a "perceived" problem, it actually happens. I would echo your
words "manually disabling the diversion of incoming telnet requests to the
webramp". When I disable something, it is not supposed to happen.
However...

> This is largely due to the Webramp's logic.  Upon receiving incoming traffic
> on port 23 the WebRamp checks it's divert port options, notices that telnet
> diversion is off, then looks for a visible computer or local server to pass
> the traffic to.  Failing this the WebRamp then defaults back to diverting
> the port 23 traffic to itself.

In other words, the M3 says "the user has told me not to divert port 23
traffic to myself, but I know better than he does where it should go, and
he couldn't possibly want anything as important as a telnet connection on
port 23 to be ignored. I'll go ahead and make the connection anyway."

> We designed this box with being able to access the CLI or HTTP interface
> from the WAN in mind.  This feature allows for remote management and trouble
> shooting of the WebRamp, and has proved to be an essential tool to our
> support department.

This is a straw man. The complaint is not that you have a way of allowing
this remote access to take place, it is that the remote connection WILL be
allowed even when you tell the M3 NOT TO ALLOW IT. If there are people
who will tell your customer service people their admin passwords and IP
addresses via email (as your customer service person wanted me to do),
that's their problem. That your box continues to offer a login prompt to
anyone who happens by after being told NOT TO, that's the problem.

> If security is a concern change the Administrative
> password on your WebRamp, and do so frequently.

Security says you do not allow connections to services you do not want
active, not that you just put a password on them. Security says that you
do not give out information about your systems that doesn't need to be
known, such as "Hi! I'm an M3 and I'm ready to let you log in, even though
you might not be able to."

In case you aren't aware of this, there are DoS attacks that don't require
passwords, just a connection. I haven't tried any of them against the M3,
but given the attitude expressed by Rampnet about this problem, I wouldn't
doubt that you can shut an M3 off remotely. I wouldn't doubt that there is
a stack smashing expoit of some kind, or who knows what else. And when
these show up, they will be branded "perceived" problems and assigned a
"level 4 priority".

I wouldn't doubt that we will learn as time goes by that there is a
backdoor that customer service uses to get into an M3 when the user
forgets his admin password. If the ability for Rampnet customer service to
connect via the WAN is so critical, it is almost a certainty. Cisco, as I
recall, had this problem. The difference is that Cisco did something about
it.

>  I would approximate this number to be in
> the 90% or higher range.  The number of customers who have actively tried to
> disable incoming telnet sessions that we are aware of is much lower than 1%.

"It isn't a security problem because very few people see it as one."
Remember, this M3 is aimed at a non-technical audience, intended for use
by people who are setting up a small office network connection to an ISP
using a modem. Most people won't think to try telnetting into their own
network, assuming that the boxes that disable diversion mean what they
say, or from pure ignorance. _I_ didn't even realize it was happening
until I disabled the visible computer and wanted to make sure it really
was disabled.

> 3)  There are workarounds readily available.

Yes, I had to waste an evening looking for one.  I wouldn't call them
"readily" available, however.  YOUR technical support people denied that
it was happening. Then they told me the commands to use to "fix" the
problem, which were actually the commands that caused the problem to
appear in the first place.

> To completely block telnet access (so that the session can't even be
> initiated) from the WAN you have two options.
>
> Method 1:  Enable a Visible Computer for each active modem port and pointing
> to IP addresses that are not being used in your LAN (e.g. 192.168.1.254 is a
> good place to start as DHCP is not likely to ever pass it out), and uncheck
> both of the divert incoming boxes.

This is the solution I told you about. Thanks for putting your official
stamp of approval on it. Your example address is a bit poor, since 254 is
a common address for gateways, and in my case isn't even on my network.

> 4)  Last but not least, engineering has agreed to incorporate a change in
> the M3 families code to mimic the 310.

How nice. I suppose a change that results in the M3 ignoring telnet
connections when it is told not to divert telnet connections to itself was
too much like an admission of a mistake.

> This would allow the user to simply
> check one box to disallow WAN access to the httpd and telnetd processes.

There is already a checkbox that is supposed to do this, at least for
telnet.

> Since there are workarounds available, and useability/functionality is not
> impaired, this is considered to be a priority 4 and may be incorporated in
> the next point release.

I'm sure I'll rush right out and buy the next "point release". Has anyone
else noticed that Rampnet does not provide free fixes, you have to pay for
every update to your firmware? Has anyone else noticed that companies like
Lantronix provide lots of free support and upgrades to firmware?

Now tell me how you are dealing with the problem of counting every packet
that comes in the modem as "activity" when it comes to timing out the
connection. This IS a usability issue, since your failure to disconnect
when there is no activity can lead to excess use charges and, in some
cases, inability to connect due to overuse. (Yes, one of the places I can
dialup has a quota, and you don't get on after you use more than X hours
in a month.) Why do you count a packet from, say, aPowWow client, that
comes in the modem and is promptly thrown away BY THE M3 itself, as valid
activity on the modem line? Why do you count leaking net-bios packets that
have no destination as valid traffic?

Right after I reported this problem, I got a few pieces of mail about it.
One was from someone who said "yeah, Rampnet support isn't very good." Two
were from people telling me this wasn't a problem, both of whom it turned
out were Rampnet dealers with a vested interest in protecting the product.
One was from the supervisor of customer support wanting to talk to me on
the phone. We talked about the problem, which he admitted was a problem,
and he promised me all sorts of status reports. I've not heard from him
since.

Every company is a good company when there is no problem. How they react
to problems is how you sort them out.