Stan writes:

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

Yes. But there's certainly no sin in that. And the changes necessary to MPE
are surprisingly small, particularly so considering the benefits that would be
derived.


>  > 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.

Based on Stan's and Chris's comments, let me propose a modified algorithm for
the IP reject file:

   o if an attempted logon fails 10 times in a row, write that IP address into
the reject file, with a time stamp, and reject all further packets from that
IP address with the standard "connection refused" message.

   o once a day, perhaps at midnight, have MPE automatically review the reject
file and purge all IP addresses that are more than 24 hours old. The
expectation would then thus be, for almost all circumstances and times, that
the reject file would be empty; after all, most HP3000s are rarely under
attack. Should an attack occur, it tends to be a transient phenomenon.

   o otherwise, accept communications from all IP addresses not specifically
barred.

While this algorithm may seem completely backwards to the standard PROACTIVE
way of doing things, especially for the more paranoid among us, it has several
significant advantages, not least of which is that it recapitulates the
informational schema of the immune system response.

The advantages I see are these:

    o It requires zero maintenance, and is thus especially appropriate to
small office and remote office use, where there may be no professional data
processing staff on hand.

    o It is completely autoadaptive. It requires no proactive maintenance of
who is to be allowed onto the system and who is not. This will become
especially important as more and more HP3000s are put onto the internet for
commercial purposes.

    o It works as well for internal attacks as it does for external ones.
Should someone gain physical access to an internal telnet terminal, he gets no
more failed attempts than someone from the outside. This ISN'T true with the
algorithm that's in place now. Someone who gains physical access to a "trusted
peer" (an allowed IP address range) has free reign at the moment to try as
many times as he likes.

    o It massively slows an attack down, which is really the key to preventing
successful entry by exhaustive enumeration. An attacker using a dialup,
automatically assigned IP address from an ISP would have to sign off and
redial to obtain a new IP address. Gavin's previous calculations for breaking
an eight-character alphanumeric password suggested an expectation time of
238,000 years. The "10 tries and you're rejected" rule would push that
expectation out sometime past the death of the Sun.

   o It is self-healing, thus a spoofed address would automatically be re-
granted access within a day, quite likely before the legitimate owner knew of
his rejection.

   o It requires minimal bookkeeping on the part of MPE. Most of the time, the
reject file would be empty -- and not contain millions of IP addresses, as
suggested.

   o It puts the burden of security back on the security structure of the
HP3000, where it should be -- and not on the communications channel.

No security is absolute, but putting this small behavior into MPE seems
sufficiently worthwhile to give it some consideration. Most importantly of
all, this form of access allowance completely eliminates the requirement for
proactive maintenance. No matter how much some people would like to be in
control of their circumstances, on the great whole, it's rarely done in the
real world by most people for most HP3000s.


Stan also writes:

>  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!)

The discouragement factor may be enough to make more than a substantial
difference.

Wirt Atmar