A fellow IT pro said that you should never need to run a virus scan on a PC because most antivirus packages scan the system in real time anyway. Is this true?

———————————————————————————————————————

While it is true that the antivirus packages will scan most files against known conditions established by the most currently installed signatures, they do not “scan” the file system in real time. The file system is effectively monitored for accesses and file manipulations done in a way that the antivirus program considers to be a threat.

Okay, let’s analyze these facts. I have attended several conferences on IT security and read more than my fair share of reference material on hacking and forensic techniques to protect computers from intrusion. While there is no gospel on this subject, most IT pros that I know, who have a fair amount of exposure in these topics, agree that no one antispam or antivirus product can catch everything.

For example, I am not picking on Symantec specifically, nor will I cite a precise example, but this issue actually happened. The antivirus had current signatures to within a few hours. The server was patched to the most current critical and recommended updates. Yet, there was suspiciously high memory usage on the server in question. It was only upon scrutinizing with Process Explorer from Systinternals, PsList (also from Sysinternals) Netstat, Task Manager, a remote UNC file connection, and a remote port scanner that I was able to confirm that there was an intrusion attempt in progress.

The server had been patched only after a 16-hour time period when a known exploited vulnerability had been published. Through this pin hole, an elevation of privilege attack had occurred. Then a hack tool was installed and a root kit planted.

The root kit hid registry keys, processes, and files from view. Once it was discovered, it was removed easily enough with known tools.

However, other problems were left behind (this was confirmed by file date stamps and checking backups) resulting in another trojan — which the AV supposedly knew about and cleaned — had hold of the machine. This is where the interesting part comes in. The trojan was not actually cleaned. There was human error in that the logs were not scrutinized to confirm that the clean attempt actually failed. This trojan was not the same iteration displayed in the AV package. As the server was being monitored using filemon, psexplorer watching threads, and Netstat, the original infection had remained.

A copy was submitted to the AV vendor anonymously and within a couple of hours, a rapid release was put out which would catch the file in real-time protection. The AV vendor said it was the same iteration of a known virus, but a programmer from a competing vendor cited the mutation differences.

While this was happening, another system was infected so the same process was used to monitor it. A real time scan was performed before the rapid release came out, and the file was quarantined successfully.

Clearly, the AV companies are doing their best to update their documentation precisely as information is put out, but the solution is critical and usually gets published faster. In part, this is likely why vendors accept anonymous file submissions — to help keep in check with viruses in the wild.

My point is just to say that the real-time AV scan does not catch everything. To be honest, a scheduled scan could miss a virus as well, but if a file has similar symptoms to a known virus, it may still have additional hidden code or functionality which can hide it from current real-time scanners.

So my answer to the questions is YES — scheduled scans on PCs would be highly recommended as part of your defense-in-depth strategy against spyware, malware, trojans, and viruses.

Brad Bird is an IT consultant in Ottawa, Canada. He specializes in Windows systems, security, and network administration. You can find more of Brad’s blogs at Rantings of an IT Pirate.

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

Read Source

The apachectl command is an often overlooked program that allows you a great deal of control over Apache processes. Vincent Danen explains the basics of this command, which you can use to debug or test Apache configurations.

—————————————————————————————————————-

The Apache Web server is arguably the best and most powerful Web server software available for any operating system. While many learn to edit the configuration files and configure or enable various modules, the bulk of what most people do with Apache is manage the content that Apache serves, with very little attention paid to what Apache itself can do.

Distributions provide initialization scripts for Apache that take the guesswork out of using it. For instance, service httpd start would start the server and an associated stop command would bring it down. These initscripts, while a convenience, largely mask the power of the command they are calling, namely apachectl.

The apachectl command is a rather overlooked program when it comes to working with Apache; however, it can be used to do some very interesting things. For instance, you can debug or test configurations by starting Apache with an alternative configuration file, leaving the working/production configuration untouched until changes can be tested. This can be accomplished with the -f option and the specification of an alternate configuration file:

# apachectl -f /etc/httpd/conf/httpd-testing.conf

This will start an Apache (httpd) process using the httpd-testing.conf file as the primary configuration file rather than the production httpd.conf.

A companion option here would be the -t option which performs a syntax check on configuration files, validating any changes you make. The command will warn if it detects any problems with the configuration file. Use it in conjunction with the -f option to validate in-progress configuration changes on non-default files: apachectl -t -f /etc/httpd/conf/httpd-testing.conf.

Another useful set of options are those that allow you to examine configuration content without actually opening and scanning configuration files. The apachectl -M command will list all loaded modules, those compiled-in and those that are shared. apachectl -l will display only those static modules that Apache loads; these would be the modules compiled into the httpd binary.

The apachectl -L option displays all available directives that Apache understands, and which module they are associated with. This is a great way to find out what options come from which module, and what they do. For instance:

# apachectl -L

<Directory (core.c)

     Container for directives affecting resources located in the specified directories

     Allowed in *.conf only outside <Directory>, <Files> or <Location>

...

The apachectl command also allows you to override directives on the command-line by using the -c option. This can be useful to temporarily test a new site or code. For instance, to override the default ServerLimit directive, use:

# apachectl start -c "ServerLimit 1024"

Other useful directives to override include DocumentRoot and Listen, among others.

Reading the apachectl manpage will provide other options and, hopefully, other ideas on how to put this often-overlooked tool to good use.

Get the PDF version of this tip here.

Vincent Danen is the Security Team Manager for Mandriva and lives in Canada. He has been writing about and developing on Linux for over 10 years.

Delivered each Tuesday, TechRepublic’s free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

Read Source

Using loops, you can take often-used commands that would normally be executed in sequence manually, and have them done automatically. Vincent Danen tells you what you need to know about getting started with loops.

——————————————————————————————————————

Creating complex commands on the command-line can be challenging the first time, but is worth the invested effort. One aid that assists in creating complex commands is loops. Using loops, you can take often-used commands that would normally be executed in sequence manually, and have them done automatically. This is perhaps one of the most useful features in command-line usage other than perhaps piping output from one command as input to another, or redirecting output of commands.

The use of loops and if/else statements will be familiar to anyone who has done any kind of programming. And while these loops can be used in shell scripts, they can also be used on the command-line itself. For instance, often I find myself executing the same command over again, but with a slight variation in arguments. Instead of executing the command once, hitting the up arrow when it’s completed, and changing one option, this can be automated to execute any number of commands in a row. It can also take advantage of using the output of other commands as input to constructing the loop.

For example, if you need to execute the same script with a varying argument, you could use:

$ for i in i586 x86_64; do seciurt 2008.1 $i foo.src.rpm; done

This command will call the seciurt script twice, the first time as seciurt 2008.1 i586 foo.src.rpm and the second time as seciurt 2008.1 x86_64 foo.src.rpm. In an instance where two arguments need to be changed in a logical format (i.e., calling seciurt to rebuild a src.rpm file for multiple distributions with the same two supported architectures), you would use:

$ for x in 2008.1 2008.0 2007.1; do for i in i586 x86_64; do seciurt $x $i foo-1.0-${x}.src.rpm; done; done

This calls seciurt six times; the first time would be as seciurt 2008.1 i586 foo-1.0-2008.1.src.rpm and the last time as seciurt 2007.1 x86_64 foo-1.0-2007.1.src.rpm. You will note that the variable $x is used two ways: $x and ${x}. The second is required to be called in that manner because there is no whitespace surrounding it and as such will match foo-1.0- instead of foo-1.0-2007.1.src.rpm, which can be seen by executing the following test:

$ touch foo1foo

$ x=1; ls foo$xfoo

ls: cannot access foo: No such file or directory

$ x=1; ls foo${x}foo

foo1foo

Remembering this “escaping” of variables can make for some very interesting CLI commands. The ability to nest loops within loops can also make things interesting with a little bit of creativity. Finally, you can use the output of other commands as input for the loop:

$ touch 1 2 3

$ for i in $(ls *); do echo $i; done

1

2

3

Here you can see the output of the ls command is used as arguments to the for loop.

Get the PDF version of this tip here.

Vincent Danen is the Security Team Manager for Mandriva and lives in Canada. He has been writing about and developing on Linux for over 10 years.

Delivered each Tuesday, TechRepublic’s free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

Read Source

Vincent Danen introduces Linux file management alternatives, Gentoo, Krusader, and Midnight Commander. Here are the basics about each if you want to try something different.

—————————————————————————————————————–

Many Linux users make use of the KDE or GNOME desktop environments and when it comes to file management, they don’t venture beyond using the environment-provided file management tools like Konqueror or Nautilus. Considering this is Linux, there are many other file management tools to choose from, some of which you may find preferable to the “defaults.”

Gentoo file manager

One such file management tool is called Gentoo, not to be confused with the Linux distribution of the same name. Gentoo hasn’t been updated in a few years, but it is still a solid file manager. Some distributions include it, so it is just an apt-get or yum command away; for others that do not include it, all you need to build it from source are the GTK+ development files and libraries. The latter will be installed with any GNOME system. To build from source, it’s a ./configure; make; make install away from usability.

Gentoo is nice in that it is a GTK+-based application with a dual-paned file view, reminiscent of old tools like Total Commander or Norton Commander. It is extremely configurable with a powerful file recognition system that allows you to map what happens when you double-click a file type, select which icons belong to what types of files, etc.

Krusader

For those who prefer using KDE, Krusader is another stellar file management tool. Like Gentoo, it is a dual-paned file management utility that is extremely customizable. The latest beta of Krusader is compatible with KDE4, whereas previous stable versions are written for KDE3. Some of Krusader’s notable features include impressive archive handling, advanced searching, an internal viewer/editor, file content comparisons and directory synchronization. It can also handle remote filesystems by using KIO slaves, which means it can mount SMB or FTP filesystems. Many distributions provide Krusader.

Midnight Commander

Finally, for those who want a file management tool very similar to Norton Commander and that operates on the CLI, Midnight Commander is the best choice. Midnight Commander is available for nearly all Linux distributions; the package may be named mc, which is also the name of the program. MC gives a dual-paned file view, each representing a different directory. When executed in a terminal under X, mouse clicks work, so if MC is your preference but you want to use it in a GUI, it’s still an option. Another nice feature of MC is that it still keeps a command-line open so you can use a combination of directory navigation and CLI commands, made even easier by using the tab key to switch active panes.

These are just three examples of many other file management, or “file commander” type programs available for Linux. Others include Tux Commander, XFE, and Gnome Commander. If the default file management tools don’t quite cut it, or if you prefer the dual-paned filesystem view, give one of these programs a try.

Get the PDF version of this tip here.

Vincent Danen is the Security Team Manager for Mandriva and lives in Canada. He has been writing about and developing on Linux for over 10 years.

Delivered each Tuesday, TechRepublic’s free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

Read Source