A Cyber-space Weapon - Chkrootkit

Rootkit is the perfect utility, that makes a hackers life easy. An ‘opportunity for mal-ware writers’ is probably an apt definition of a rootkit. These tools enable administrator-level access to a computer or computer network. Root-kits have become more common and their sources increasingly difficult to identify. They leverage security exploits and trojans to deceive a user into trusting the installation is not malign.

Root-kits comprise of a set of trojanized system utilities and daemons. It comes with additional programs and Kernel Modules, that are designed to conceal the very presence of malicious programs. Rootkits are used to hide different utilities which the intruder uses to gather data or to abuse of the system.

CHKROOTKIT - An anti rootkit software

Chk-rootkit is a simple and feature-full Unix-based program to check the system for known rootkits, which is basically a utility to help detect sniffers, Trojans, worms, and other back-door programs. It is basically a shell script that makes use of simple linux commands to check for any discrepancies. Using it is as simple as “download, untar, make and execute” in most cases. You can have chkrootkit installed through the steps given below.

-> Download the tar file to a folder say, ‘/opt’

cd /opt/; wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

-> Compute and check MD5 message digest of the download as part of the security feature. This helps to verify the integrity of the tar balls or source code.

ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5
md5sum chkrootkit.tar.gz

-> Unpack the tar file

tar xvzf chkrootkit.tar.gz

-> Change to the directory into which it was unpacked

cd chkrootkit-*

-> Compile the installation with the following command

make sense

-> chkrootkit can be run as

./chkrootkit

Chkrootkit can be set up as a ‘Daily automated system scan job’ that emails you a daily report, or it can be set up as a ‘Cron job’ at whatever schedule you may prefer.

Chkrootkit as Daily Automated System scan

Create a file and insert the content as given below.

vi /etc/cron.daily/chkrootkit.sh
#!/bin/bash
cd /opt/chkrootkit*/
./chkrootkit | mail -s “Daily chkrootkit from Servername(replace with server name)” “admin@youremail.com”

Change the permission

chmod 755 /etc/cron.daily/chkrootkit.sh

Run the test report

cd /etc/cron.daily/
./chkrootkit.sh

Chkrootkit as Scheduled Cron

Add the following cron entry for root, using crontab

3 3 * * * (cd /opt/chkrootkit; ./chkrootkit 2>&1 | mail -s "chkrootkit output" "admin@youremail.com")

Chkrootkit can easily identify a trojaned system command, while it looks for known “signatures” in system binaries. But in some cases, it is possible that the attacker has modified the rootkit sources, to change its signatures and thereby avoid chkrootkit detection. Chkrootkit checks for all known signatures inside a file. Hence, it can’t automatically determine if it has been trojaned. In such cases we may need to run the chkrootkit in the ‘expert’ mode. The expert flag, -x, outputs strings taken from the binary files it analyzes.

./chkrootkit -x | more

In this mode we can examine suspicious strings in the binary programs that may indicate a trojan.

Rootkits represents a looming threat of the future. It is important that we do not allow an attacker to mask intrusion. Chkrootkit is an Intrusion Detection System that helps to prevent potential harm that can be caused due to the existence of loopholes in the system. It makes life easier by helping distinguish the malicious from the legitimate. However, we still await a tool that would heal injuries, and prepare your server for the next battle in the Cyber-Space!

RootKits - An Introduction

Ever heard of a situation where a security expert/data-center asks to re-install the OS of a server for security reasons? That sounds like(and in fact is) a drastic situation, and it does happen. The risk of living with a server that was once compromised is very high. The risk it is due to the possibility of a rootkit implanted in the server. Unfortunately the only proven recovery method would be a clean install of the OS.

What is Rootkit

Root-kit typically is a malware that is stealthy in nature. They are usually hard to detect, and harder to remove. A rootkit can potentially hide almost any software; including files, botnets, key-loggers and back-doors. Root-kits are implanted in a system by an attacker who gains access to the system using some inherent vulnerability in the system.
Once the system is rooted, the options for remedying the scenario is limited. Due to the stealthy nature of rootkits, it is almost impossible to ascertain the level to which the system is compromised. Many a times the system binaries and libraries are tampered with, hence one could no longer rely on these infested binaries. The only safe course, is a complete wipe of system and a fresh install of OS.

How RootKits are detected

Rootkit detectors use few standard methods for detecting the presence of rootkits :
-> Based on Signature - The idea is to look for specific files and binaries that are part of known root-kits. This is not fool-proof for the very fact that signatures of known malware could change every now and then. Also, newer rootkits would never be identified, as they are still an unknown entity.
-> Based on behavior - Behavior-based detectors identify rootkits by finding hidden elements, which is mostly finding an anomalous behavior of a server. Say the network interface entering promiscuous mode, or a similar activity.
-> Comparison/Integrity based - Here comparison of present output with the desired output is used to detect the presence of a rootkit. Say the command ps gives one output, while the status of processes in /proc has a different tale to tell. Also checking the sanity of system tools with methods like MD5 hash compare, and changed attributes of system files.

How to mitigate the rootkit

Taking a few steps can ensure the health and integrity of the servers. The process involves :
-> Proper security measures to protect against unauthorized access to server/data.
-> Proper means to detect rootkits; in case security is compromised at some point of time.
-> Being ready for a recovery, if need arises
There are many tools available, that help in detecting a possible rootkit. Do keep an eye out for posts on a few of them in the coming weeks.

VPN

As a Webhost with more than a few servers, the benefits of having a private network setup between your servers are many. This private network allows your servers to communicate and transfer data securely among themselves. Most DCs offer this as an added feature to the services they provide. Previously, to access this network you would have to look for the expensive option of renting a leased line to the DC, but not anymore. This can now be achieved using a VPN.

Ok, Now what is a VPN?

VPN stands for Virtual Private Network. It allows you to connect securely to a private network over the Internet, and work as if you were a part of that network. It is based on the client/server architecture and it works on almost all platforms; including FreeBSD, Linux, Windows and MAC OS X. A VPN can be used to provide remote access to a private network or to connect two geographically separated private networks, using the Internet to carry the traffic. If you have outsourced your support team, you can have them setup a VPN between their network and the private network at the DC, allowing for improved productivity and security.

Is there a cheap VPN solution?

There is, and it is called OpenVPN. OpenVPN is a free and open source VPN solution and can be used for any of the scenarios mentioned above i.e. You can use it to connect your PC to the private network at your DC, or to connect your network, your support team’s network and the DCs private network together. OpenVPN employs both encryption and authentication to guarantee the safety of the data being transferred. For encryption it employs another open source package OpenSSL. It employs pre-shared secret keys, certificate-based, and username/password-based authentication.

Setting up a VPN:

Let us look into setting up a VPN between a client PC and a server.

Installing Open VPN on the server:

Open VPN requires the “lzo” real time compression library, so you should install it first if it is not already present. There are various methods by which you can install OpenVPN and installing it using YUM is the easiest. It will also install “lzo”, along with any other required packages. To install, simply run the command:

yum install openvpn -y

It is also possible to install OpenVPN from source, which will give you much more control over the installation, but is fairly complicated.

Once the installation is over you will see the configuration and binaries at the path: /usr/share/doc/openvpn-2.1/easy-rsa.

Copy this folder to the /etc directory.

We will have grant all permissions to the scripts in this folder.
cd /etc/openvpn/easy-rsa/2.0
chmod 777 *

Create Keys on Server:

Now that the server has been installed, we will now have to setup the keys that will be used by the VPN client/server for authentication. Here we will be using the public key infrastructure (PKI) method for authentication. In this method, there will be three certificates.

1) Master certificate & key which is placed in vpn server
2) Server certificate & key which is placed in vpn server
3) Client certificate & key which is placed in vpn client

We will generate the master certificate below. The server will only accept the certificates from those clients which are signed by the master certificate authority.

Generate the master Certificate Authority (CA) certificate & key:

The scripts in the easy-rsa folder are used for generating keys. The keys will be placed in /etc/openvpn/keys. This folder will not be present by default and has to be created.
mkdir /etc/openvpn/keys
In order to generate the master certificate, we first need to edit the “vars” configurations file located at /etc/openvpn/easy-rsa/2.0
Edit the following values to suit your requirements. Do not leave any of those fields blank as the cert will be generated based on these values.

export KEY_DIR="/etc/openvpn/keys"
export KEY_COUNTRY=”US”
export KEY_PROVINCE=”CA”
export KEY_CITY=”SanFrancisco”
export KEY_ORG=”Fort-Funston”
export KEY_EMAIL=”test@test.com”

Now, we will start creating the cert and key.
#. ./vars
#./clean-all (This will delete all the existing files in the key folder)
#./build-ca (We are going to build the CA. You can just continue by hitting Enter until you reach the field for common name. All other fields will be populated by default from the entries you gave in the vars file)
You will then be asked for some details to be specified for the certificate. It is important that you give a unique value for the “Common Name” parameter. Now that the master certificate has been generated we shall proceed to generate the server certificate.

Generate certificate & key for server:

./build-key-server server
As in the master certificate almost all parameters are taken by default from the vars file. The only detail that you need to provide is again the “Common Name. Here I have used “server.ca”. You can then continue hitting enter, until you reach the“Sign the certificate?” field. Type “y” and hit enter. Next it will ask “1 out of 1 certificate requests certified, commit?”. Again type “y” and hit enter.

Generate certificate & key for client:

Now we proceed to create the certificate and key for client. It is exactly the same process as above and make sure that there also you give a unique “Common Name”. You can create as many keys as there are clients you wish to connect to the server.
./build-key client1
Here I am generating the certificate for the client named client1. Enter the common name and proceed as you did with the server certificate.

Generate Diffie Hellman parameters:

Next we will proceed to generate the Diffie Hellman parameters. Diffie-Hellman (D-H) is a public key algorithm used for producing a shared secret key.
The script for generating D-H parameters is called ./build-dh and is located in the same scripts folder.
# ./build-dh

Configuring the Open VPN client:

Upload the ca.crt, client1.crt and client1.key to the client PC.
Now that the client and server side configurations are over, we will proceed with editing the configuration files, which is the most important part.

Creating configuration files for the server:

Sample configuration files will be available at /usr/share/doc/openvpn-2.1/sample-config-files. The server.conf is the server configuration file and you can copy it to /etc/openvpn and modify as needed.
cp /usr/share/doc/openvpn-2.1/sample-config-files/server.conf /etc/openvpn
A sample configuration file is given below. The fields which you need to edit are the ones which have been explained with a # mark to the right.
=========================
port 1194
proto tcp
dev tun
ca keys/ca.crt # path to the CA.crt file
cert keys/server.crt # path to the server certificate
key keys/server.key # path to the server key file
dh keys/dh1024.pem # path to the generated D-H parameters
mode server # implements multi-client server capability
tls-server
tls-cipher DHE-RSA-AES256-SHA
server 192.168.1.0 255.255.255.0 # here give the private network address in the server and its mask.
client-config-dir ccd
#########
######### Put your Public DNS Servers here
#########
#push “dhcp-option DNS 210.80.150.4″
#push “dhcp-option DNS 202.155.174.4″
push “route 192.168.1.0 255.255.255.0″ # The OpenVPN server can push routes, DNS server IP addresses and other configuration details to the clients.
ifconfig-pool-persist ipp.txt
push “redirect-gateway”
keepalive 10 120
comp-lzo
persist-key
persist-tun
status server-tcp.log
verb 3
========================

Once the configuration is over, create the file ipp.txt which contains the IP s of the clients you wish to connect to the server.
A sample ipp.txt file is as follows.
# cat ipp.txt
test1.com.client,192.168.1.4

---

Next, touch a file for the logs.

touch server-tcp.log

Configuring the Client:

Depending on the OS of the PC you are using to connect,(Windows, Linux/Unix) you can download an OpenVPN client that suits your needs and install it. Other than adding the keys as mentioned above, you will not have to make any configuration changes on the client.

Starting the VPN:

Once the server and client side configurations are over, we can start the open vpn server.
/etc/rc.d/init.d/openvpn start

Once OpenVPN has been started you should be able to access the server as if it were part of your private network.

For more detailed steps on setting this up, check out my complete articlehere.

Deploying ProFTPD: Open source FTP server software

Proftpd is a highly configurable and modular FTP daemon, whose configuration and setting up is almost similar to the web server Apache. The installation, pre and post install configuration are discussed briefly in this document.
The document requires fair knowledge of Linux and Apache webserver.

Installation.

Installation is done through ./configure script. By default, proftpd and ftpshut are installed in /usr/local/sbin/, ftpcount and ftpwho in /usr/local/bin/, the configuration file in /usr/local/etc/, and the man pages in /usr/local/man/man?/. Further, /usr/local/var/proftpd/ is used to hold the runtime scoreboard files. See the “Directory and file names” section of the ./configure –help output for the arguments to change these defaults. For instance, to place all these directories under /usr/ rather than /usr/local/, you could use:

$ ./configure --prefix=/usr

Or, to place the configuration file in /etc/ and the runtime state files in /var/proftpd/, you would use:

$ ./configure --sysconfdir=/etc --localstatedir=/var

1. Optional modules

$ ./configure --with-modules=mod_readme:mod_ldap

Some operating systems require you to use either –enable-autoshadow or –enable-shadow if you wish to use the system’s shadow password file for user authentication. Using autoshadow allows proftpd to work with either shadow or traditional password files.

If you wish to use SQL for user authentication, you must specify mod_sql and one SQL backend module, either mod_sql_mysql or mod_sql_postgres. Further, the backend module must be specified later in the module list, e.g. –with-modules=mod_sql:mod_sql_postgres. Otherwise, compilation will succeed, but SQL authentication will not work.

2. Verify correct configure operation.

Watch the output of the configure script. After configure has run, you may wish to inspect the config.h file to make sure configure didn’t make any wrong “guesses” for your platform.

3. Modify the proftpd configuration file.

This default configuration causes Proftpd to run as stand alone server.

ServerType Standalone

This configuration causes Proftpd to run as a subserver of inetd/xinetd

ServerType inetd

4. Modify the inetd/xinetd superserver configuration file.

Edit /etc/inetd.conf and then send the inetd process the HUP signal, so that it will reread the updated configuration file. On some systems there are other mechanisms to tell inetd to reread its configuration file, e.g. refresh -s inetd on AIX. Check your system documentation to see what command is appropriate.

If proftpd is to be run from inetd, find the line in /etc/inetd.conf that looks something like:

ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd

And replace it with:

ftp stream tcp nowait root /usr/local/sbin/proftpd proftpd

Or, if the tcp wrappers package is installed on your system, you may use a line something like:

ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/proftpd

If proftpd is to be run in standalone mode, you should comment out any ftp line in the /etc/inetd.conf file by inserting a # at the beginning of the line. Then signal the inetd process to reread /etc/inetd.conf.

If your system is using xinetd instead of inetd then either edit your /etc/xinetd.conf file or add a proftpd file in /etc/xinetd.d/:

service ftp
{
flags = REUSE
socket_type = stream
instances = 50
wait = no
user = root
server = /usr/sbin/proftpd
bind =
log_on_success = HOST PID
log_on_failure = HOST RECORD
}

5. Create the runtime state directory.

In order for the MaxClients and MaxClientsPerHost directives and the ftpwho and ftpcount utilities to work, proftpd must have a directory to hold its scoreboard files. The default is /usr/local/var/proftpd/, though it may have been changed in the configuration process in Step 2. The default location also can be overriden at run-time by using the ScoreboardPath directive in the proftpd.conf configuration file. Whatever diretory is used, it must exist prior to starting proftpd. If you have installed from an installation package, the installation scripts may have created the default directory. Nonetheless, if it does not already exist you must create it manually. No special permissions are needed on the directory, unless you wish to restrict who is allowed to run ftpwho and ftpcount.

Testing the Software

As of ProFTPD 1.2.0, there are no automated regression tests. However, you are encouraged to perform your own ad-hoc, manual tests.

Note that you can start proftpd directly from your shell prompt, but do remember that it must run as root for all functions to operate properly. Nonetheless, many operations can be verified without root privileges. An alternate configuration file can be specified using the -c command line switch. In the configuration file, the TCP ports may be changed from the standard default ftp (21) and ftp-data (20) ports, and an alternate passwd file may be specified. Since such a daemon will not be able to change its uid, you also must specify the user and group names to match those used to start the daemon.

To demonstrate this process, a set of example config files have been included in the sample-configurations subdirectory.

% sh sample-configurations/PFTEST.install
Sample test files successfully installed in /tmp/PFTEST.
% ./proftpd -n -d 5 -c /tmp/PFTEST/PFTEST.conf

Then, in another window, connect to the unprivileged port. PFTEST.conf uses port 2021, and PFTEST.passwd defines a user “proftpd” with password “proftpd”. Using the traditional Unix ftp client, it might look something like this:

% ftp -n -d
ftp> open 2021
ftp> user proftpd
---> USER proftpd
331 Password required for proftpd.
Password: [proftpd]
—> PASS proftpd
230 User proftpd logged in.
ftp>

Commands for showing the run time details

ftpshut : Sutting down the server at a particular time.
ftpwho,ftpcount :Shows No:of users connected
proftpd :command line interface

For more information refer man pages.

The important Proftpd Configuration Files

/etc/proftpd.conf -------------> Main conf file

/etc/proftpd/passwd.vhosts-----> Proftpd passwd file(AuthUserFile)

.ftpaccess -------------------->Overriding file, like .htaccess

The configuration is similar to httpd.conf and includes mainly three sections.

* Global environment.
* Main server configuration.
* Virtualhosts configuration.

Important configuration sections and directives are as below

Virtual-Hosts(For dedicated IPs) and Anonymous Users configuration

ExtendedLog /etc/httpd/domlogs/ftp.domain.com-ftpbytes_log READ BytesLog
TransferLog /etc/httpd/domlogs/ftp.domain.com-ftp_log
ServerName ftp.domain.com
AuthUserFile /etc/proftpd/user
MaxClients 3 "Sorry, this ftp server has reached its maximum user count (%m). Please try again later"
DirFakeGroup On ftpgroup
DirFakeUser On ftpuser
DefaultRoot ~    //The default ftp home directory(which is usually /home/user/)

AllowOverwrite on
HideGroup wheel
HideUser root

UseFtpUsers on
RequireValidShell off
User ftp
Group ftp
UserAlias anonymous ftp
DisplayLogin welcome.msg
DisplayFirstChdir .message

DenyAll

AllowAll

DenyAll

Main Server Configuration

Add this to your proftpd.conf

# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use. It establishes a single server
# and a single anonymous login. It assumes that you have a user/group
# "nobody" and "ftp" for normal operation.

ServerName "ProFTPD"
AuthUserFile /etc/proftpd/passwd.vhosts
LogFormat BytesLog "%b"
ServerType standalone
DeferWelcome off
DefaultServer on
DefaultRoot ~ !wheel
TransferLog /usr/local/apache/domlogs/ftpxferlog
Port 21

Simple Management for BIND

Smbind is a PHP-based software tool for managing DNS zones for BIND via the web interface. This supports the per-user administration of zones, error checking, and a PEAR DB database backend.

1. INSTALLATION

Please download the smbind tar file from the download section using wget.

# wget http://jaist.dl.sourceforge.net/sourceforge/smbind/smbind-0.4.7.tar.gz
# tar -zxvf smbind-0.4.7.tar.gz
# cd smbind-0.4.7/

You will need to create a database, table structure, install and configure the PHP scripts, and modify your named.conf. You will need to adjust permissions on your system so that your web server user (www, apache, httpd, nobody, etc.) can read and write various files relating to BIND, such as rndc.

2. DATABASE

You will need to create a database, table structure and then copy the dump file smbind-mysql.sql to the respective database.

Create the smbind database.

[MySQL]         mysqladmin create smbind
[PG]            createdb smbind

Create the smbind tables.

[MySQL]         mysqldump smbind < smbind-mysql.sql
[PG]            psql -U dbuser -d smbind < smbind-pg.sql

3. WEB SERVER

Copy the contents of the php directory to a web server directory.

# cp -Rp php/* /usr/local/apache/htdocs

Secure the config file (private readable) and template_c (writable) directories. Your web server may not run as apache, it may run as www, httpd, nobody, or something entirely different.

# chown root.apache config.php template_c
# chmod 640 config.php
# chmod 775 template_c

Download the latest version of Smarty from http://smarty.php.net/. Untar the file, and copy the libs folder to the location specified in the smarty_path option in the config file config.php.

# mkdir /usr/share/smarty
# tar zxvf Smarty-2.6.1.tar.gz
# cp -R ./Smarty-2.6.1/libs/* /usr/share/smarty

Edit config.php, setting your database information and the locations of your named-checkconf, named-checkzone, and rndc binaries. smbind configuration examples are provided for both normal and chroot jailed BIND setups.

The typical config.php file with all necessary configurations will be as follows:

// Include paths.
$_CONF['smarty_path']   = “/usr/share/smarty”;
$_CONF['peardb_path']   = “/usr/share/pear”;

// Database DSN.
$_CONF['db_type']       = “mysql”; // mysql for MySQL, pgsql for PostgreSQL
$_CONF['db_user']       = “smbind”;
$_CONF['db_pass']       = “newpass”;
$_CONF['db_host']       = “localhost”;
$_CONF['db_db']         = “smbind”;

// Zone data paths (normal).
$_CONF['path']          = “/var/named/”;
$_CONF['conf']          = “/etc/smbind/smbind.conf”;
# Include this file in named.conf.

// Zone data paths (chroot).
#$_CONF['path']         = “/var/named/chroot/var/named/”;
#$_CONF['conf']         = “/var/named/chroot/etc/smbind/smbind.conf”;
# Include this file in named.conf.

// BIND utilities.
$_CONF['namedcheckconf'] = “/usr/sbin/named-checkconf”;
$_CONF['namedcheckzone'] = “/usr/sbin/named-checkzone”;
$_CONF['rndc']           = “/usr/sbin/rndc”;

Provided is a configtest.php script that will test permissions on everything to ensure that your configuration will work. It will be located at http://localhost.localdomain/src/configtest.php

4. BIND

Add the user that runs your web server to the group that runs the BIND server. This will allow BIND to access it’s files, while also allowing your web server to update and manage them. The example below assumes that apache is running as “apache” and that BIND is running as “named”. Apache must then be restarted.

# usermod -G named apache
# /etc/rc.d/init.d/httpd restart

Create a directory for the smbind zone file.

# mkdir /etc/smbind
# chown root.named /etc/smbind
# chmod 775 /etc/smbind

Add an include to your named.conf, adding smbind.conf to named.conf.

include "/etc/smbind/smbind.conf";

Modify the permissions on BIND’s zone file directory. Some distributions do not even allow named to write to its own zone directory.

# chmod 770 /var/named

5. TESTING OUT

Fire up a browser and view http://localhost.localdomain/src/configtest.php This script will verify that your web server can read and write every where it needs to. If it encounters any permissions problems, read the error message carefully and investigate as instructed. It is assumed that your BIND is running prior to this test.The typical configtest will output as follows:

smbind configtest

This script will try to check some aspects of your smbind configuration
 and point you to errors where ever it can find them. You need to edit
config.php and read the INSTALL file first before you run this script.

Testing config.php...OK
Testing PEAR DB...OK
Testing Smarty...OK
Testing templates_c...OK
Testing path...OK
Testing conf directory...OK
Testing conf file...OK
Testing named-checkconf...OK
Testing named-checkzone...OK
Testing rndc...OK
Testing (guess) /etc/rndc.conf...OK
Testing (guess) /etc/rndc.key...OK
Testing (guess) connection to localhost:953...OK
Testing rndc execution...OK
server is up and running
Testing database connection...mysql://smbind:newpass@localhost/smbind OK
Testing database SELECT from zones table...OK
Testing database SELECT from users table...OK
Testing database SELECT from records table...OK
Testing database INSERT into zones table...OK
Testing database INSERT into users table...OK
Testing database INSERT into records table...OK
Testing database UPDATE zones table...OK
Testing database UPDATE users table...OK
Testing database UPDATE records table...OK
Testing database DELETE FROM zones table...OK
Testing database DELETE FROM users table...OK
Testing database DELETE FROM records table...OK

Congratulations, your setup looks good. Please remember to add the
following line to your named.conf:
include "/etc/smbind/smbind.conf";

Web interface

Login to the web interface http://domainname/php/src/main.php
with the user 'admin' and password 'admin'.