How To: Kaspersky Anti-Spam

Every network administrator at some stage in their career will come into trouble with the influx of spam during their career because, quite simply, spammers are smart. If you did a Google search for “Linux Anti-Spam”, you’ll be bombarded with tutorials using the infamous, free, SpamAssassin software. However if spamassassin isn’t quite cutting it, you may want to give Kaspersky Anti-Spam 3.0 a whirl. (Please note, Kaspersky Anti-Spam 3 isn’t free and requires a per mailbox licensing fee)

The name Kaspersky is gaining quite a name globally, originally an Anti-Virus engine; Kaspersky Labs has developed tools to help assist network managers fight malicious attacks in all forms of life; spam, viruses, spy-ware and phis-hing attempts. Kaspersky’s anti-spam product, titled appropriately, Kaspersky Anti-Spam 3.0, is able to integrate with your existing Linux smtp engine to filter spam for your users. Kaspersky Anti-Spam (and from now on known as KAS) is able to integrate with;

- Qmail
- Sendmail
- Exim
- Postfix

Getting started

The first step is to obtain the package which suits your Linux distribution. For the sake of simplicity, we’ll install KAS using the debian packaged file.

Grab Kaspersky Anti-Spam here

dpkg -i kas-3-3.0.284-1.i386.deb

Once KAS has been installed, it will show on the screen a number of steps you must perform to complete the installation. This includes installing the license key, enabling automatic updates and integrating KAS with your SMTP engine.


You’ll need to transfer your kaspersky anti-spam license key file (.key) to the server so you can perform the following task;

/usr/local/ap-mailfilter3/bin/install-key /path/to/your/keyfile.key

The great thing about KAS3 over KAS2 is the web interface. Kaspersky Labs has developed a web interface, allowing you to configure various components of the software.

To access the web interface from a computer other than the one KAS is installed on, you’ll need to make a change to this file;

nano /usr/local/ap-mailfilter3/etc/kas-thttpd.conf

and uncomment the line


Finishing up

Once that’s done, you can simply type in your browser; http://ip-of-kas-server:3080 and whola! You’re away. I won’t delve into how to configure the application as its pretty self explanatory. Simply hit the policy page and configure the action rules, which state what should happen to SPAM once detected (whether it should be deleted, redirected etc).


Rootkit Detection and Removal

The other day I noticed something weird when I performed the command “ls -l”. Bash was reporting some strange output and the first thing I did was throw it into Google…. which revealed one thing; my Linux box had been comprised. Freaked out at first, I started researching everything I could; I was already aware of tools such as rkhunter and Chkrootkit and this was the first thing I did. RKHunter confirmed what I thought, my server had a rootkit, a SHV5 Rootkit to be correct. The compromised server was used in a web hosting environment and had all the usual services running such as; ftp, http, smtp, dns, pop3, imap etc. After some “intense” googling, I revealed that many sites and forums stated the three R’s to root kit removal;

Repartition, Reformat, Reinstall

And whilst I agree that the above actions are the only 100% way to ensure your system is completely rootkit free, I offer advice on how you can get get up and running without having to rebuild or disappoint your clients *gasp*.

Please take the following advice with caution – we cannot be held responsible for any further damage that you may cause. Further to that, this article is “always updating” – should you have further advice as to assist with the removal of Rootkits – please feel free to chip in and lend a hand.


The first step is to detect what Rootkit you have and there are two well known tools to do this;

- RKhunter
- Chkrootkit

Cleaning up

The first thing you should do once you KNOW what rootkit you have, is to Google any information you can. What you want to do is find out exactly what the rootkit does and often there are detailed posts or whitepapers which explain this.

In my case, the SHV5 rootkit replaced quite a few system binaries with its own “trojan’ed” version, designed to hide any suspicious activity from the system administrator. An example of commands that were replaced were; ps, ls, top, lsmod, find, netstat etc. (As you can see, these are essential tools to help clean out the rootkit! We need our originals back asap!)

The SHV5 rootkit also set the immutable attribute on core system commands, making it “undeletable”. To check what files the Rootkit may have infected, use the “lsattr” command.

root# lsattr /bin

You may see something like;

s---ia------- /bin/netstat
------------- /bin/zcat
s---ia------- /bin/mv
------------- /bin/date
s---ia------- /bin/cp
------------- /bin/grep
s---ia------- /bin/ls

The files that have the “sia” flags set have most likely been compromised and you are advised to replace them from your package maintainer. The flag “i” represents immutable, meaning it cannot be modified, renamed or deleted.

If you run a system that uses RPM’s, you’ll most likely have to delete the package that contains the above compromised tools, before you can replace them. As this is a dangerous move (deleting crucial commands), I suggest you get everything in place before you proceed.

Simple download the packages you need. In my case I needed the following;

- coreutils-x.i386.rpm
- findutils-x.i386.rpm
- net-tools-x.i386.rpm
- proccps-x.i386.rpm

Once downloaded I performed the following commands;

Because RPM won’t let me uninstall a package that has files with immutable set, I did the following;

chattr -ias /bin/ls
chattr -ias /bin/find


rpm -e coreutils.i386 --nodeps
rpm -i coreutils-x.i386.rpm

And I did this for all the files that I knew were compromised. Now that I had my everyday system commands back up and running, I could explore further.

Always check the /tmp folder, as this is most likely where the rootkit was first introduced. The /tmp folder is used by many web applications which is often the method of intrusion. In my case I found /tmp/r00t … interesting? I ziped up the folder and stored elsewhere for later viewing. (Oh and I also rm -rf’ed the prick :))

The SHV5 rootkit installs itself under /usr/lib/libsh – and removing this folder is probably a good idea.


Once you’ve got your core system commands back, you can perform an analysis of the situation, digging deeper to see what else has changed. For example;

- netstat -an
Use this command to verify which ports on your machine are open and awaiting information. SHV5 has the ability to run a hidden shell session, listening on a particular port.

- lsof
Cycle through the output this command generates and see what files are being used by the system.

Good luck!


Some handy sites to assist;

- Linux RootKits For Beginners – From Prevention to Removal
- Analysis of RedHat 8.0 Honeypot Compromise

Ezbounce tutorial

Ezbounce is a cool peice of software that has many useful features for the hardcore IRC user. If your a regular IRC user who wants to hide your identity, stay connected to channels whilst offline and have a centralized IRC session – be sure to check this guide out.

From the ezbounce website.

ezbounce is an Internet Relay Chat (IRC) proxy server.
Features include:

* Multi-user support
* Full access control (ban and allow lists)
* Full IPv6 support
* Secure Sockets Layer (SSL) support
* Lots of tweakable settings

Obtaining ezbounce
The first thing you will need to do is install the software onto an available Linux machine. You will need to recompile this from scratch, so make sure you have the appropriate gcc compilers already installed.

james[/home/james]# wget

(If that doesn’t work – the link might be dead – head to the official download site)

Next we need to extract the ezbounce files.

james[/home/james]# gunzip ezbounce-1.04b.tar.gz
james[/home/james]# tar xvf ezbounce-1.04b.tar

cd to the newly created folder. The next step is to configure and compile ezbounce. We can do this with the following commands.

james[~/ezbounce-1.04b]# ./configure
james[~/ezbounce-1.04b]# make
james[~/ezbounce-1.04b]# make install

If all goes well the executable should appear in the folder your currently in. Next we need to configure ezbounce.

Ezbounce comes with two config files, one with minimal options and another containing all possible options.

For this guide we’ll just use the minimal one (ezb.conf). Open up ezb.conf in your favourite text editor. Most of the options you can leave by default. You’ll want to edit the user bracket. Here is an example.

user lego
		from *
		to *
	set is-admin 1
	set password pass123
	set enable-incoming-dcc-proxying 1
	set enable-outgoing-dcc-proxying 1
	set enable-detach-command 1
	set enable-auto-detach 1
	set enable-vhost-command 1
	set enable-fake-idents 1


This user block allows me to connect to any server, FROM any location. The “is-admin” makes me an admin and “password” line sets my password. You may read the readme for a more in depth explanation about each available option.

Next, run ezbounce!

james[~/ezbounce-1.04b]# ./ezbounce ezb.conf