Wirt writes:
> >  Causing a service interruption, potentially...a larger scale interruption
> >  than simply turning off the modem.
>
> No. There is absolutely no reason that a simple, fully automatic, completely
> transparent-to-the-user mechanism can't be put into MPE, essentially identical
                                    ^^^^^^^^^^^^

Ah...you're not talking about what MPE *is*, but what it *could be*.

I agree that changes could be made to tighten telnet security, to make it
similar to modem security.  And what would we have then?  A mechanism
that, *aside from the hangup problem*, is *STILL* more insecure than
a modem.  Clearly.  Why?  Consider this: you would now have exactly the same
logon attempt security (and I'm willing to disregard the minor speed difference
that slightly benefits the telnet hacker vs. the modem hacker :).
Are there any other differences?  Yes.  BY SIMPLY HAVING THE HP 3000 ON THE
NET, YOU'VE OPENED UP A SECURITY HOLE (where "Security" includes service
interruptions) ... a hole that's larger and different than having
a modem connected.

A hacker can dialup the modem, and lean on the carriage return key.  This
will cause a large number of interrupts per second, and affect service.

A hacker can *also* telnet in and do the equivalent...*FAR* more times
per second, interrupting service more.
Worse, they can initiate connection attempts to other ports (if allowed
by your firewall), similarly taking up CPU at the minimum, and
getting more access at the worst.

> If a particular remote IP address accrues 25 (or 50 or 100) failed logon
> attempts in 1 (or 4 or 6 or 24) hours, that remote IP address could then be
> written into a file of non-accepted IP addresses. This file would essentially
> be the antithesis of INETDSEC.NET.SYS. Rather than specify the list of

Good idea!  I wouldn't put a time limit on it ... if the IP address fails
10 times in a row, bar that IP address.

Of course, a hacker can fairly easily generate 25 (or 50 or 100) attempts
over telnet *MUCH* quicker than over a modem (several orders of magnitude
quicker) ... even if the connection is broken after 3 consecutive failures.
Add to that the ability to generate/use more IP addresses, and we see that
the "disable particular IP address" isn't a cure all.  (Although it should
still be implemented, because it will discourage many hackers!)

BTW, we haven't even discussed IP spoofing or network sniffing security
problems with telnet access :)

Hmmm...a hacker with IP spoofing software *might* be able to use the
"deny after 10 failed attempts" to lockout legitmate IP addresses...which
is another form of service denial.

What about tapping?
It's harder for a hacker to tap your phone, generally, than your network.
(Although if they have physical access to your site, all bets are off,
of course.)

> This would cause no interruption to any other user and yet provide you with a
> automatically adapting system -- one that actually provides you with a great
> deal of safety, at virtually no cost to a true user's ease-of-use. Further,
> this no-management, auto-rejection mechanism would not only tend to be very
> secure, it would be compatible with the philosophy of small office HP3000s,
> where there is no professional data staff on hand to constantly monitor
> security issues.

Agreed...it's a good idea, but one that doesn't change the fact that
telnet access is fundamentally less secure than phone access.

I forget, did someone discuss the traceability of a phone call vs
a network connection?

> As I tell all of our customers, the order of real-world threats remain in this
> order: fire, flood, internal deceit, external deceit, with each item on the
> list being about 1/10th or 1/100th the probability of the one above. This

I'd add "government intervention" in there somewhere, possibly after
external deceit.  As Steve Jackson Games can tell you, it's a serious problem.

And, based on recent events, flood is far more likely to happen to some people
than fire :)

Two weeks ago, the hot tub in the physical therapy office on the other side
of the wall from our computer room overflowed...we were lucky, most equipment
was an inch off the floor.

Stan (the roof isn't leaking ... must mean the rain stopped) Sieler