Unix network security (waas \"CERT Internet Security Advisory\")

rackow at skeeve.mcs.anl.gov rackow at skeeve.mcs.anl.gov
Sat Aug 19 23:29:04 AEST 1989


I do not think that any of the suggestions at ".netaccess" would have
helped in the most recent version of security breaches.  Since what my
understanding of the problem was/is had to do with legitimate usage
being "taped/bugged" by a bogus telnet program it would do you little good
to have a ".netaccess" file.  I guess it would help from random crackers
at random hosts trying to break passwords.  But in this case- since the
real user wanted access from what proved to be a "untrustworthy" machine
to get to another machine he had (or would have) put the "untrustworthy"
host into the list.  If the cracker was carefully monitoring the log
from his bugus telnet, he could have quickly logged into the remote host
as the user and examined the dot files to see where else he could come from. 
If you were alerted to the problem, you could remove the original bad host,
but would that be enough???

I believe in having minimal amounts of hassle in getting from placce
to place and the greater need and benifits of an "open" network so
take the following and pipe to all flames to /dev/null. ;-)

----Start of paranoid security state------
A possibility for the security paranoid and those with large human
memories would be to make the netaccess file include passwords (or
shadow passwords with the location of the shadow file hidden from the
user as well).  Now you can have a "*" to allow all hosts with a 
password.  When you login from a new host, it forces you to pick a
new "generic" password and adds the new host to the access list and requires
a new password for that host as well.  The passwords can not be duplicated
for any host in the list with all the crazy rules of non-word mixed case
etc., etc....  (Like I said--large human memory.)  You probably would want to
put the access into "syslogd" as well so the admin can keep track of where the
users are and be alerted of possible breaches.  This would make it easier
to knock the bad host out of the list, but the cracker could still have been 
playing havoc with your login for some time.  Of course I never want to
see this implemented, because my memory is not that large.
----End of paranoid security state------

Maybe the real solution would be the little personal crypt boxes that
when you attempt to login give you a string you enter into your box. Your
reply to that string is the output from your little box.  I do not know
how secure these things are, or if you can use one box for more than 
one host, but sometime in the next millenium this problem will probably
be solved and we'll be dealing with a whole new set of problems. ;-)

   Gene Rackow                    email: rackow at mcs.anl.gov
   Math & Computer Science        voice: 312-972-7126
   Argonne National Labs          FAX:   312-972-5986
   9700 S. Cass Ave.
   Argonne, IL  60439



More information about the Comp.unix.wizards mailing list