virus scan programs

[Jerry McAllister]

> 
> Dear freeBSD enthusiast,
>      Greetings.  I am a newcomer to the BSD/Unix world.  My place of
> employment is a large agency with thousands of client machines.  Most of
> the clients use Microsoft Windows 2000 Professional operating system.  Most
> of the servers use either Novell operating system, or I.B.M. Domino
> operating system.  

Wow, you live on the edge [of impending disaster]!!   I hope they 
pay you well.

> A very important ritual that each client computer
> performs every morning at boot-up time is to run a virus scan application
> program.  This program is run whether or not the user desires it, because
> it runs before the user us granted a log-on screen.  

Given what you are running, it is a good practice.

> In my reading of Unix
> and BSD literature, I have found no mention of virus scan programs for
> these operating systems.  Do such programs not exist? 

It depends on what you are scanning for.   There are scanners that 
scan Email passing through the Email server of a FreeBSD (or similar) 
system - and destined for a Microsoft client - used to help protect 
those Miscrosoft clients.    And, there are general spam blockers to
help reduce the volume of annoying trash.   But, in general, the UNIX
systems are naturally quite well protected against Email born attacks
of the type that plague Microsoft systems.   There is no such thing
as sending Emails to one of those machines that will execute some code
upon arrival or upon opening the message.  I hope that "feature" never
comes to any UNIX Email client. 

It is possible to try and attack a UNIX system, but the technique is
quite different than the easy stuff that is done to trash MS systems.
On UNIX, there are three general types of attacks.  

One is to look for things that have been left open.  Some systems used
to be delivered with accounts that had no password or with a known
standard password that the sysadmin was supposed to change upon
setting up the system - BEFORE connecting it to the net.  Well, too
often some of these got left unprotected.  Most systems no longer
are distributed with open accounts or accounts with known passwords.
Either the installation proceedure gives you the opportunity to set
up an administrator account with password or you have to know how
to get in to the system using direct access to the console.

Another method is to try and find passwords to accounts that have been
created, especially root accounts.   This is done by stealing passwords
from careless people, guessing passwords of people who don't have much
imagination with creating them and by running cracking routines.
If a person can get any access to a system, by getting a legitimate
account or guessing the password to a poorly protected account, it is
easy to get a copy of the password file.   It is a misnomer, because 
the password file does not contain any passwords.  They are in another
place that is only root readable and are one-way encripted.   BUT, in
the "password" file is a list of users which the evil cracker reads up
and uses to try and guess passwords.  They have programs that are
pretty good at guessing if the password is somewhat systematic and
related to the users login id or other recorded information.   The 
cracker just keeps trying those password guesses until one works.
The best protection is to not put passwords (eg *-out the passwords) on 
any accounts that have priviledge and to use difficult to guess passwords 
on regular user accounts.

The third method attempts to use weaknesses in the system.   These
come in a couple of flavors.   Some are things like telnet, ftp and
Email servers that manage connections to the system.  Some of these
transmit userids and passwords in clear text and someone on the net
can read those.   In addition, code errors are occasionally found
that can possibly be used to crash a routine in such a way as to
be able to execute some other piece of code as root.  If someone 
figures out how to do this, they tend to set themselves up with a
way to get regular root access to the machine.  Then they can do
almost anything they want.  This is called making a rootkit.   But, 
though a few of these have been found over the years, they are fairly 
difficult to create and so they don't happen with great frequency - 
unlike the MS exploits which seem to come in mass quantities.   

The main protection against these types of attacks is good system
administration.  Make sure unneeded paths in to the system are not
left open.   Make sure connections to the system are legitimate for
which utilities such as tcpwrappers and firewalls are a big help. 
Make sure users use terminal access that encripts sensitive information 
(such as ssh instead of telnet).  There are scanning type routines that 
are used to detect these sorts of intrusions.  They tend to look for 
things that can run as root and make sure they are legitimate and have 
not been modified from a standard.  The common one is chkrootkit.
Many systems are set up to automatically run attack checkers on frequent 
intervals using the system cron.

>   Alternately, is the
> Unix/BSD approach to this problem in a different philosophical and/or
> procedural sphere?  If so, could you describe the Unix/BSD approach to
> locating and eradicating these invaders of one's hard drive?  If the issue
> is already explained in either printed literature, or posted at a world
> wide web site, it is sufficient to cite the location.  Many thanks for your
> response.

It is a different world than Microsloth, partly due to an inherently
more secure system, partly because it isn't as much fun for juvenile
delinquents to attack UNIX systems as it is to attack MS systems 
because they aren't as well known and partly because it is more 
naturally possible to protect the system using standard UNIX tools.

This is not to say that it is not possible to attack a UNIX system
or that it never happens.   It is possible and does occasionally
happen.  So, learn as much as you can about system security.
Attend a SANS conference.   Read handbooks, web articles and
published books on the topic.

////jerry
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>