From: seborg@csrc.ncsl.nist.gov (Brian Seborg)
Newsgroups: comp.virus
Subject: more network security
Date: 29 Sep 92 15:43:02 GMT

Vesselin Bontchev writes:

>As a conclusion, it is a bad idea to rely on virus disinfectors.
>Just delete the infected programs and replace them with clean
>backup copies.

I am glad that you have finally reached this conclusion. :-)  We
have been saying this for years!

In another posting, Vesselin writes:

>seborg@csrc.ncsl.nist.gov (Brian Seborg) writes:

>> some dismay.  Regarding the "new trend" to allow your computer
>> to boot off of the C: drive rather than the a: drive, this is 
>> not new.  Hasn't anyone heard of a Zenith 248?  The military
>> only has about 650,000 of them.  This boot redirection has been
>> re-definable in cmos for some-time.  We're talking pre 1988 
>> here.

>The "new" in the trend is that nowadays more and more BIOS
>producers are providing this feature.

Thanks for the clarification, I was just surprised that we were
giving lauds and praises (and free advertising) to manufacturers
who are just now beginning to do what Zenith did over 4 years ago,
that's all. :-)

>> Regarding Cohen's paper, I guess I am somewhat tired of hearing
>> about a paper that I do not have a copy of and perhaps that is
>> making me somewhat testy, but let's be serious about network >>
security.  I hope 

>The paper is in the proceedings of the 2nd Virus Bulletin
>conference. You can order the proceedings from Virus Bulletin.

Thanks, let me just pull out my wallet... :-)

>The point in Cohen's paper is that the "obvious" way to set a
>Novell LAN is insecure, not that it is not possible to set it up
>in a secure way, or that it can be set up in an insecure manner. 

Again, who said that securing a network was "obvious"?  Many
networks are set up in an unsecure way.  There are many reasons for
this: lack of understanding, lack of time, lack of expertise, it's
more difficult to secure a network properly than to just get it to
work correctly, no understanding of security principals or common
threats, etc.  It is good to have papers point out that the "most
obvious" ways of setting up a network are insecure, or that lack of
security in network environments is common, but this comes as no
surprise to security professionals.  No doubt this information (as
you related it) will be of use to Novell administrators, but only
if they understand that security is a priority, and then only if
they are given the resources by management to accomplish the task
of securing the network.  The bigger problem is that securing a
network which has been operating in a non-secure manner for some
time, is probably more of a political and managerial problem than
it is a technical one.  Ask anyone who has to do this for a living.

>I have quoted the secure settings listed in his paper in one of my
>previous messages.  Take a look at them, then take a look at the
>LANs you have seen. Are they set up in this (secure) way? Till now
>only Padgett has succeeded to figure out himself what the secure
>settings are... The average supervisor usually makes a mistake or
>two, exactly because the secure settings are not obvious. And the
>equations that I quoted concern only the effective file rights. If
>you try to take into account all inheritance masks, the task
>becomes even more difficult.

As I stated in my posting, I work in a Banyan environment, Fred's
paper has little if any relevance to my environment given that it
is Novell specific.  Also, it seems that you and others are just
getting into networks, be careful that you do not assume that
securing a single server represents mastery of the topic.  I
understand that Padgett may have sufficient experience to make this
claim, but I doubt that he is the "only" administrator to succeed
in successfully securing his network. :-)

>> need to quantify security policy, but taking common practices
>> and reducing them to set notation for the sake of publishing a
>> paper seems to do nothing to advance the field.

>I disagree. The paper clearly lists what the secure settings are,
>mentioning why any other settings can be bypassed. It emphasizes
>that the ExecuteOnly attribute should not be trusted, because it
>can be easily bypassed - and do you know how many Novell LAN users
>rely on it for protection? 

Do you know how many DOS users rely on setting the DOS Attribute to
Read-only for protection?  But I see that this can be useful.

>> 1) Set the access rights for applications drives (file-services)
>> to read only for all users including administrators.
>> Administrators can always change the permissions back >>
temporarily when making updates or changes, but will be
>> protected from inadvertently infecting the system in general.

>Unfortunately, under Novell NetWare and Unix, the person with
>supervisor (root) privileges can bypass the protection, without
>having to modify the permissions...

I know, and that's a good point.  However, I address this with
another control in the posting stating that administrators (super-
users) should maintain two accounts, one privileged, and one with
standard privileges, and that they should use the standard account
for day-to-day use. :-)

>> Some programs require users to have modification rights to
>> applications directories.  My experience suggests that most
>> programs of this sort can be set up so that users are given
>> modify rights to some files which are put in a separate >>
directory, and the application itself can still be
>> write-protected.  This is true for Paradox for 

>It might be true for Paradox, but it isn't for dozens of other
>applications... But I agree with you that such applications have
>to be avoided.

Vesselin, you are a master of restating the obvious.  Is there an
echo in here? :-)

>> 2) If possible, do away with all file services where multiple 
>> user's have write-access (except in small groups).  "Bit Bucket"
>> file services where everyone has write access are good places
>> for Trojan Horse programs, companion, and path companion viruses
>> (or standard trojans), and, in addition, are hard to manage
>> since determining ownership is a problem.  If you must have
>> these type of file services, limit the number of users (i.e.
>> fragment them into smaller chunks, by  functional working group
>> for example), don't allow any .bat, .com, .exe, files to reside
>> in these directories.  Any applications, including batch files,
>> should reside in write-protected areas.

>As I have described in my paper (available by anonymous ftp),
>there exists a form of virus attack, involving PATH-companions and
>at least one writable directory - be it the user's home directory
>on the server, or one of the local workstation's directories. The
>attack is not specific to Novell and allows a virus to bypass any
>protections and to make all protected applications to look and
>behave as if they are infected. Fortunately, the infection does
>not spread between users.

I see no contradiction with my recommendations, especially since
the type of attack you suggest still does not represent a threat to
the network if you follow the above guidelines.

>> Also, make sure that user's path statements do not contain 
>> directories where multiple people have write-access.  This is
>> not only unnecessary, but dangerous as well.

>Problem is, the PATH variable cannot be protected at all, due to
>the lack of memory protection in Messy-DOS...

True, but again, this does nothing to contradict the usefulness of
the control I suggest, you merely have suggested another attack
which this control does not protect against.  Securing a network or
any computer is a matter of minimizing risk.  There is no such
thing as a 100% secure system.  I see little point in dwelling on
threats which present minimal risk when there are the more likely
threats of a disk crash, or accidental erasure, etc.  We would do
well to address these risks before worrying about the threat of
someone re-setting our path variable.  

>The rest of your suggestions are very sound and should be
>carefully followed by all LAN users, regardless of the LAN type.

Thanks...I think.  The only thing which bothers me about the above
statement is that it infers two things, 1) That you are an
authority on the subject.  If this is so, it is commendable since
your postings indicate that you have only recently begun to work
with networks; 2) That there are some of my suggestions which are
not sound, if so, which ones?

Sincerely,

Brian Seborg
VDS Advanced Research Group