Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!mailrus!purdue!haven!adm!xadmx!rackow@skeeve.mcs.anl.gov From: rackow@skeeve.mcs.anl.gov Newsgroups: comp.unix.wizards Subject: Re: Unix network security (waas \"CERT Internet Security Advisory\") Message-ID: <20653@adm.BRL.MIL> Date: 19 Aug 89 13:29:04 GMT Sender: news@adm.BRL.MIL Lines: 47 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@mcs.anl.gov Math & Computer Science voice: 312-972-7126 Argonne National Labs FAX: 312-972-5986 9700 S. Cass Ave. Argonne, IL 60439