After comments by several on this subject, Wirt proposes:

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

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

May I suggest one additional refinement:  If and when we can
get HP to do this, while they are at it allow for a *configurable*
number of hours between "purge all IP addresses"...  oh, and it
should be configurable *online*.... If nothing else, remember that
there are weekends.... might not want the IP reject file to be
cleaned out while all staff is gone for two or three days.... but 24
hours would be a good default value....

> The advantages I see are these:

>    o It requires zero maintenance,

A big advantage all by itself....

>    o It is completely autoadaptive.

Yup.

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

Not only "physical access to an internal telnet terminal":  There
is also of course the possibility of effectively gaining *virtual*
access to an internal telnet "terminal"....  Let me give y'all a
very brief and sanitized (for security purposes) history of an
actual event at a certain Government facility that I am aware of,
that occurred in the not very distant past:

A reasonably sophisticated hacker broke in to a computer at a
college back East somewhere.  S/He gained root access to a
UNIX system;  I think it was a Sun Workstation.  Said hacker
proceeded to make some mods to the OS on the computer s/he
cracked;  and then proceeded to "lift" the entire modified OS
kernel (whatever all that included;  I don't recall all the details).

Said hacker(s) then went "looking around" at the aforementioned
Government facility for a similar machine (before they had a more
effective firewall).  Found one or more....  got in...  FTP'd his/her
cleverly modified OS into the new target, and booted from it... At
which point the hacker(s) managed as I understand it to look like
a completely legitimate "local user" while they rummaged around
at will and at considerable length on the large local network from
that *internal* machine that they took over, running Sniffer and
quietly gathering all sorts of "interesting" data....  oh, yeah:  This
was a malicious attack:  I believe at least two machines had to
be rebuilt from scratch from backup tapes;  and there was a major
denial of service....

Which bed-time story leads me to mention again the other 3000
network security enhancement we have talked about for years
now:  Even if I'm careful about keeping good passwords on every
MPE user / account, if anyone can gain a "presence" on a local
network and they know a few basic Sniffer procedures, all they
need to do is monitor for a bit to pick up all MPE user-account
logons and passwords that fly by *in the clear* from VT or TELNET
termulator sessions...  In which case any implementation of an IP
reject file becomes worthless, since the hacker can get the logon
right the first time..  Even with firewalls, with network connections
becoming increasingly pervasive, surely this situation is becoming
more and more unacceptable ??...  *Surely* termulator vendors
and CSY could get together on this ??.  or at least one termulator
company ??...   ;-)


SUMMARY:  I request that Wirt's proposal for an "IP reject file"
(with my small modification) be added to the SIGMPE enhancement
list.  The "ability to encrypt MPE logon info" should already be there
somewhere....

Ken Sletten