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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:40 PDT