ServerBuddies Support Blog

Using RPM Verify to Monitor Changes to System Files

It is important for administrators of critical server systems to be able to track changes to files on their systems. Tracking file changes helps detect accidental or malicious modifications such as viruses, root kits, or hacking activity. RPM, the package management system used for all RPM based Linux distributions, provides an easy mechanism for tracking these changes. When a package is installed, the RPM database stores information about each file belonging to that package including the size, date, and MD5 sum among others. This data can later be compared to the existing files on the system to detect any changes.

Verifications are performed with the rpm command and the -V flag. This command should be executed as root so that all file attributes can be read from the system without file permissions getting in the way. For example:

To verify all files in the RPM database:

To verify all files belonging to a package, packagename:

To verify all files belonging a particular RPM file (local, FTP, HTTP):

All applicable files are checked, and any discrepancies are shown. The output is a string of eight characters, followed by an optional attribute marker. The string of eight characters indicates changes in size, permissions, MD5 sum, etc.

For example:

This example shows that the configuration file, /etc/wvdial.conf, has a different size, MD5 sum, and modified time than the RPM database has on record. In this case, this is probably okay–it is a configuration file and it is normal for them to change.

Nikto2 web server assessment tool Install.

Nikto is a web server assessment tool. It is designed to find various default and insecure files, configurations and programs on any type of web server.

Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1000 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software. Scan items and plugins are frequently updated and can be automatically updated.

Installation

Any system which supports a basic Perl installation should allow Nikto to run. For SSL support the Net::SSLeay Perl module must be installed (which in turn requires OpenSSL on the Unix platform).

Download - http://cirt.net/nikto/nikto-2.1.3.tar.bz2

Unpack the download file:

Basic Testing
The most basic Nikto scan requires simply a host to target, since port 80 is assumed if none is specified. The host can either be an IP or a hostname of a machine, and is specified using the -h (-host) option. This will scan the IP 192.168.0.1 on TCP port 80:

To check on a different port, specify the port number with the -p (-port) option. This will scan the IP 192.168.0.1 on TCP port 443:

SELinux in Ubuntu

SELinux is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources. SELinux can be enabled in Ubuntu by installing the “selinux” meta-package, which will make the needed changes to the system, and install the Tresys policies for Ubuntu:

After installation, you will be prompted to reboot the system to label and activate SELinux.
When using SELinux, files, including directories and devices, are referred to as objects. Processes, such as a user running a command or the Mozilla® Firefox® application, are referred to as subjects.

The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:

In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. With DAC, access is controlled based only on Linux user and group IDs. It is important to remember that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.