IFS

How many times have you written scripts and a had bad time with those having spaces? The remedy to this situation is your IFS value.

IFS or Internal Field Seperator holds the value which seperates the various entities. This can be file names, values read into a script by read etc. It is the character or characters designated as whitespace by the operating system.

The IFS is set to the newline and space character. The global variable $IFS stores the value. To view the exact value stored in IFS execute:

echo "$IFS" | cat -vTE
 ^I$
$

Running echo “$IFS” will not give you any visible output (after all, you are going to see a space and a newline). cat -vTE displays non printable characters , tabs as ^I and ends each line with a $ sign.

In a script which utilises filenames (with spaces), it is always preferable to change the IFS to include only the newline character opposed to the default space and newline character. Lets check out one such script which accepts filenames wih spaces. This scripts simply prints the file names in your current directory. (Remember to create some files in your currenct directory which has spaces. You may try the same script removing the lines with the IFS variable in reference to see the difference)

#!/bin/bash
OIFS=$IFS # Original IFS

IFS=$(echo -en "\n\b") # New IFS

for fil in $(ls -1 $PWD); do
	echo $fil
done

IFS=$OIFS # Restore earlier IFS

IFS can also be used to read files with lines sepearated by a special character. For example in the /etc/passwd, to store the various entries like username, homedirectory etc.

The following script uses the while construct to determine the users who have the shell portion as /bin/false

#!/bin/bash

OIFS=$IFS
IFS=':'

while read username password userid groupid comments homedir shell_avail
do
	if [[ $shell_avail == /bin/false ]]; then
                echo "$username has no shell"
        fi

done < /etc/passwd
IFS=$OIFS

In the above script each of the 7 portions of the /etc/passwd file is assigned to the 7 variables
username password userid groupid comments homedir shell_avail with the read command. The if portion in the script compares the seventh variable – shell_avail to /bin/false to determine the username and outputs it.

From now on you can use the IFS variable for all those files with spaces and extracting values separated by a special character.

Tweet This Post

RootKits and anti rootkits

A rootkit is a collection of programs that enable an attacker to get the same privilage as the root user in a linux or unix system. The word is composed of two portions: ‘root’ – meaning the application will provide the highest access level of the root/administrator in the system and ‘kit’ – meaning it has a number of tools.

Attackers after getting access to a server, will install a rootkit to hide their identity and run desired scripts anywhere within the server. It makes the life of a hacker easy once installed. Rootkits are not easily detectable. Sometimes, if the rootkit is one of the latest ones without a diagnosis, the server will have to be rebuild from scratch.

A rootkit will have multiple applications for cracking the entire server, some of them are:

Server Access Applications (Back door application)
These applications will create a backdoor to log in to the hacked system without using the exploit again.

Log clearing Applications
These applications clear the logs of the events performed by the hacker or the applications used. They all the associated log files in the server.

Packet sniffing Applications
These applications monitor the data through the various interfaces in the server at particular ports.

Malicious Scripts
Many scripts will be installed like IRC bots, ddos daemons, spam servers, trojans, worms etc.

There are mainly two kinds of root kits. The application rootkit and the kernel rootkit.

Application rootkits
These rootkits mimic a particular application and will hide the attackers files/processes from being revealed by the original application. To illustrate, a rootkit ls application will perform all the task of a normal ls but will not display any of the files of the attacker. Other application rootkits will create backdoors for unauthorised access, packet sniffers etc which go undetected or are hidden by renaming. Application rootkits are the most common.

Kernel rootkits
Kernel rootkits modify the kernel and apply patches to the kernel and device drivers. They also hide the applications and files of the attacker. As antivirus and other applications run beneath the kernel, they are the most undetectable rootkits.

‘Prevention is better than cure’ – as this saying goes, it is always better to keep the system secure and updated when ever possible to stop these installations. There are some applications which help detect any known rootkits running in the system. One such is the chkrootkit.

chkrootkit is one of the popular rootkit detectors (an anti-rootkit) and it is know to detect common rootkits on unix/linux servers. chkrootkit relies on basic string processing techniques to determine the presence of rootkits. It scans specific sytem files and binaries targeted by rootkits for known signatures.

The following are the instructions to install chkrootkit version 0.49 in a server.

cd /usr/local/

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

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5

md5sum -c chkrootkit.md5 # to check if the downloaded file is intact

tar -xzf chkrootkit.tar.gz

cd chkrootkit-0.49/

make sense

./chkrootkit

chkroootkit will check all the files and display the status of the files analysed. This information may be logged for future reference. For this a cron job may be setup to be run at least once a month.

Inserting an entry like the one below into the systems cron tasks (executed atleast once a month) will send the report of the chkrootkit vulnerabilities to the administrator conserned.

/usr/local/chkrootkit-0.49/chkrootkit | mail -s "chkrootkit report $(date +%d/%m/%y)" "admin@domain.com"

Tweet This Post

MySQL Storage Engines – an overview, their limitations and an attempt for comparison

Most of us are using Mysql database and majority don’t know how to choose the data base engines, what are the different types of storage engines available in mysql and how they differ from each other. In this article let me give you a brief idea about the Storage Engines and what are the limitations and where to use these various storage engines.

One of the greatest things about MySQL, other than being free, widely supported and fast, is the flexibility of choosing different storage engines for different tables. These storage engines act as handlers for different table types. Thus MySQL storage engines include both those that handle transaction-safe tables and those that handle non-transaction-safe tables along with many others. MySQL does this through their Pluggable Storage Engine Architecture.

MySQL Storage Engines Overview

To determine which storage engines your server supports, we use the SHOW ENGINES statement. The value in the Support column indicates whether an engine can be used. A value of YES, NO, or DEFAULT indicates that an engine is available, not available, or available and currently set as the default storage engine. (Continue Reading)

Tweet This Post