Linux and Viruses

Authored by Madhu M Kurup and Babu Kalakrishnan

The

first week of May 2000 saw the nasty "I Love You" virus destroy

data on PCs all over the world, causing damage worth billions of dollars.

And it isn’t the first time such an event has occurred (remember Melissa

just a few months back)? Significantly, not even one of the PCs running

Linux was affected. Does this mean that Linux is immune to viruses? Or is it

just that virus writers haven’t targeted Linux machines as yet?

Is Linux really immune?

A virus or

virus-like program can be written for any operating system. There have been

reports of at least one replicating virus–Bliss, May 1997–specifically

targeted at Linux executables. Destructive code can also be written very

easily using scripting languages like Perl available on most Linux

distributions. Even a bash script can be quite powerful.

The relative immunity of

Linux stems from the implementation of security at the operating system

level. If a user executes a piece of destructive code, the files that the

program can infect or destroy are restricted to those for which the user has

permissions to write to. All the binaries of the standard programs are

normally installed with write permissions only to the super-user (root) and

hence can’t be modified (unless you’re running the program as root).

Read the Linux Security HOWTO to understand why you shouldn’t be doing

that anyway.

Open Source is secure

Another

reason why Linux is relatively immune to virus attacks, is because most

software used in Linux is available either as Open Source or free software.

A major mode of propagation of viruses is through cracked or pirated

commercial software, where you can’t verify the authenticity of the copy

you obtained. As for Linux applications, most are freely downloadable from

the Net, and cryptographic signatures of packages are generally available at

the official Websites of the distributors. So, you can verify the

authenticity of the package, even if you obtained the software from a

different source.

In addition, the most vital

aspect of Linux-based software is that the source code is always available

for anyone to read, inspect, and verify. Backdoors, loopholes, and other

exploits quickly get detected, given that you can compile your own version

of a program. Sometimes, availability of the source is considered a

weakness, as access to the source code supposedly permits flaws in the

operating system to be found easily. However, you should realize that Linux

is a huge community effort, and that at any point, hundreds of people are

co-operating towards finding, solving, and securing loopholes in the

operating system.

To understand what logrotate can do....

To understand what logrotate

can do, first ask yourself what you want to do with your log files. The

table "Planning for a log processing and archiving policy" might

help you to start. The first row lists the processing and reporting to be

done, while the first column lists the files on which the processing is to

be done. Put down the different log files in column 1, tick out the log

processing of your choice, and you can come up with a policy for using

logrotate.

Let me briefly explain what

each column implies. A "yes" on column 2 indicates that you want

to retain the log file as a record, so it’s best kept compressed.

Similarly, a "yes" in column 3 indicates that you merely want to

scan the file, look for the unusual, and then discard it. You might want to

mail this file to yourself or to the relevant administrator. Column 4 says

that you want to discard the file straightaway. In the sysadmin world, this

obviously doesn’t qualify for best practice. Columns 5 and 6

mention the actions you want to perform before and after you do the log

processing. Column 7 is for an e-mail address to which errors during log

processing are to be reported, and column 8 indicates how often you want the

processing to be done. Note that you might want a time threshold with a

granularity of a day or choose to have a file size threshold to rotate the

logs. This table is not exhaustive or mandatory in nature–it’s is merely

an example of how you would go about the policy-making exercise. So, don’t

implement this, as is, as a policy. Evolve one to suit your needs.

If you’re ready with a

table such as the one above, you have a policy. You can now use logrotate to

implement this policy.

The policy is specified using

keywords, as well as with a script-like language comprising keywords

specific to logrotate. The script is intuitive and easy to understand. By

default, most logs are rotated four times, uncompressed, before they’re

removed from the system. This should explain the presence of files with the

extensions .1, .2, .3 and .4 in the /var/log directory. Take the file /var/log/messages

as an example. After a certain time period or after a certain file size is

reached (as specified in /etc/logrotate. conf), this file is renamed to

messages.1 and an empty file called messages is created to take in the new

log input. This is repeated until they’re rotated four times.

Let’s look at a portion of

the configuration from /etc/logrotate.conf from a standard install. The

first line mentions the name of the file for which the policy is laid out.

Notice the intuitive keywords–"monthly" indicates that the

rotation cycle is monthly, "create" specifies the permissions and

ownerships to be used when the old file is moved to another name and an

empty file is created. "Rotate 1" indicates that one rotated

logfile will be retained:

/var/log/wtmp

{ monthly

create 0664

root utmp

rotate 1

}

Here’s a portion of the

file /etc/logrotate.d/apache–the policy for processing apache log files.

The keyword missingok implies that if the log file isn’t found, continue

processing the rest. Notice the command in between the keywords postrotate

and endscript. This command is executed after log processing is done.

Surprisingly, you don’t find any other instructions such as the frequency

of rotation or the number of rotations, as in the previous case. When there’s

no explicit mention made, the definitions in the global configuration file

will apply.

/var/log/httpd/access_log

{

missingok

postrotate

/usr/bin/killall -HUP httpd 2> /dev/null || true

endscript

}

logrotate is typically run

once a day by the cron. If you are logged in as superuser, you would see an

entry similar to the one below in the crontab file:

0 0 * * * /usr/sbin/logrotate

The utility runs every

midnight. You can run it more often if you need to.

A good start towards

minimizing disk storage space would be to uncomment the compress option in

/etc/logrotate. conf, so that all the rotated log files are kept compressed.

Avinash

Shenoy is a systems and network administrator at the NCBS, Bangalore,

and Gopi Garge is a technology

consultant with Exocore Consulting <www.exocore.com>