Posts Tagged ‘Installing’

Scanning shared hosting servers to catch abusers, unwanted files, phishers, spammers and script kiddies with clamav

Friday, August 12th, 2011

Clamav scanning shared hosting servers to catch abusers, phishers, spammers, script kiddies etc. logo

I’m responsible for some GNU/Linux servers which are shared hosting and therefore contain plenty of user accounts.
Every now and then our company servers gets suspended because of a Phishing websites, Spammers script kiddies and all the kind of abusers one can think of.

To mitigate the impact of the server existing unwanted users activities, I decided to use the Clamav Antivirus – open source virus scanner to look up for potentially dangerous files, stored Viruses, Spammer mailer scripts, kernel exploits etc.

The Hosting servers are running latest CentOS 5.5. Linux and fortunately CentOS is equipped with an RPM pre-packaged latest Clamav release which of the time of writting is ver. (0.97.2).

Installing Clamav on CentOS is a piece of cake and it comes to issuing:

[root@centos:/root]# yum -y install clamav
...

After the install is completed, I’ve used freshclam to update clamav virus definitions

[root@centos:/root]# freshclam
ClamAV update process started at Fri Aug 12 13:19:32 2011
main.cvd is up to date (version: 53, sigs: 846214, f-level: 53, builder: sven)
WARNING: getfile: daily-13357.cdiff not found on remote server (IP: 81.91.100.173)
WARNING: getpatch: Can't download daily-13357.cdiff from db.gb.clamav.net
WARNING: getfile: daily-13357.cdiff not found on remote server (IP: 163.1.3.8)
WARNING: getpatch: Can't download daily-13357.cdiff from db.gb.clamav.net
WARNING: getfile: daily-13357.cdiff not found on remote server (IP: 193.1.193.64)
WARNING: getpatch: Can't download daily-13357.cdiff from db.gb.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
Downloading daily.cvd [100%]
daily.cvd updated (version: 13431, sigs: 173670, f-level: 60, builder: arnaud)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 144, sigs: 41, f-level: 60, builder: edwin)
Database updated (1019925 signatures) from db.gb.clamav.net (IP: 217.135.32.99)

In my case the shared hosting hosted websites and FTP user files are stored in /home directory thus I further used clamscan in the following way to check report and log into file the scan results for our company hosted user content.

[root@centos:/root]# screen clamscan -r -i --heuristic-scan-precedence=yes --phishing-scan-urls=yes --phishing-cloak=yes --phishing-ssl=yes --scan-archive=no /home/ -l /var/log/clamscan.log
home/user1/mail/new/1313103706.H805502P12513.hosting,S=14295: Heuristics.Phishing.Email.SpoofedDomain FOUND/home/user1/mail/new/1313111001.H714629P29084.hosting,S=14260: Heuristics.Phishing.Email.SpoofedDomain FOUND/home/user1/mail/new/1305115464.H192447P14802.hosting,S=22663: Heuristics.Phishing.Email.SpoofedDomain FOUND/home/user1/mail/new/1311076363.H967421P17372.hosting,S=13114: Heuristics.Phishing.Email.SpoofedDomain FOUND/home/user1/mail/domain.com/infos/cur/859.hosting,S=8283:2,S: Heuristics.Phishing.Email.SSL-Spoof FOUND/home/user1/mail/domain.com/infos/cur/131.hosting,S=6935:2,S: Heuristics.Phishing.Email.SSL-Spoof FOUND

I prefer running the clamscan in a screen session, because it’s handier, if for example my ssh connection dies the screen session will preserve the clamscan cmd execution and I can attach later on to see how scan went.

clamscan of course is slower as it does not use Clamav antivirus daemon clamd , however I prefer running it without running the daemon, as having a permanently running clamd on the servers sometimes creates problems or hangs and it’s not really worthy to have it running since I’m intending to do a clamscan no more than once per month to see some potential users which might need to be suspended.

Also later on, after it finishes all possible problems are logged to /var/log/clamscan.log , so I can read the file report any time.

A good idea might also be to implement the above clamscan to be conducted, once per month via a cron job, though I’m still in doubt if it’s better to run it manually once per month to search for the malicious users content or it’s better to run it via cron schedule.

One possible pitfall with automating the above clamscan /home virus check up, might be the increased load it puts to the system. In some cases the Webserver and SQL server might be under a heavy load at the exactly same time the clamscan cron work is running, this might possible create severe issues for users websites, if it’s not monitored.
Thus I would probably go with running above clamscan manually each month and monitor the server performance.
However for people, who have “iron” system hardware and clamscan file scan is less likely to cause any issues, probably a cronjob would be fine. Here is sample cron job to run clamscan:

10 05 01 * * clamscan -r -i --heuristic-scan-precedence=yes --phishing-scan-urls=yes --phishing-cloak=yes --phishing-ssl=yes --scan-archive=no /home/ -l /var/log/clamscan.log >/dev/null 2>&1

I’m interested to hear if somebody already is using a clamscan to run on cron without issues, once I’m sure that running it on cron would not lead to server down-times, i’ll implement it via cron job.

Anyone having experience with running clamscan directory scan through crond? 🙂

Installing HTOP on CentOS 5.5 OpenVZ Linux server from source

Friday, July 22nd, 2011

Htop Cool picture logo / htop on CentOS OpenVZ

Lately, I’m basicly using htop‘s nice colourful advanced Linux top command frontend in almost every server I manage, therefore I’ve almost abondoned top usage these days and in that reason I wanted to have htop installed on few of the OpenVZ CentOS 5.5 Linux servers at work.

I looked online but unfortunately I couldn’t find any rpm pre-built binary packages. The source rpm package I tried to build from dag wieers repository failed as well, so finally I went further and decided to install htop from source

Here is how I did it:

1. Install gcc and glibc-devel prerequired rpm packages

[root@centos ~]# yum install gcc glibc-devel

2. Download htop and compile from source

[root@centos src]# cd /usr/local/src
[root@centos src]# wget "http://sourceforge.net/projects/htop/files/htop/0.9/htop-0.9.tar.gz/download"
Connecting to heanet.dl.sourceforge.net|193.1.193.66|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 418767 (409K) [application/x-gzip]
Saving to: "download"

100%[======================================>] 418,767 417K/s in 1.0s
2011-07-22 13:30:28 (417 KB/s) – “download” saved [418767/418767]

[root@centos src]# mv download htop.tar.gz
[root@centos src]# tar -zxf htop.tar.gz
[root@centos src]# cd htop-0.9
[root@centos htop-0.9]# ./configure && make && make install

make install should install htop to /usr/local/bin/htop

That’s all folks! , now my OpenVZ CentOS server is equipped with the nifty htop tool 😉

Installing SuPHP on Debian Lenny 5.04 with Apache 2.2.9

Thursday, February 18th, 2010

My daily duties as a sys admin today included installation and configuration of SuPHP .
SuPHP is an apache dynamic module for executing PHP scripts with the permissions of their owners. It consists basicly of twoparts Apache module (mod_suphp) and a setuid root binary (suphp). The suphp module is invoked by the mod_suphp module and instructsApache to change the user id (uid) of the process executing the PHP script.
SuPHP is not a standard Apache module so it’s not 100% tested. Therefore from security point of view it’s better not to use SuPHP.
So beware use it at your own risk! You better know what you’re doing if you’re installing this piece of soft.

The official SuPHP documentation is rather I would say archaic and it’s completely out of date. Though according to the official documentation it’s noted that suphp module won’t work with Apache 2.2.x, it actually works perfectly fine.
I’ve checked and I couldn’t find any tutorials on installing suphp on Debian Lenny therefore I decided to write this tutorial to shed some light on it.
So enough talk let’s approach to the installation and configuration of suphp;

1. Install the module itself from the debian package

debian-server# apt-get install libapache2-mod-suphp
Debian will enable the mod_suphp automatically after installation, though this kind of behaviour is pretty stupid, since it won’t disable mod_php5 which is enabled by default.

2 Therefore we need to disable mod_php5 from executing to enable suphp.

debian-server# a2dismod php5

3. Enable suphp globally for the Apache
Edit /etc/apache2/apache2.conf and put in the end of the configuration file

# Enable SuPHP
suPHP_Engine on
suPHP_AddHandler application/x-httpd-php .php

In my case I’m not using Debian’s default DocumentRoot website location for both my Apache and my VirtualHosts, therefore I need also to configure
suphp.conf

4. Edit /etc/suphp/suphp.conf and change;

;Path all scripts have to be in
docroot=/var/www/

to let’s say:
;Path all scripts have to be in
docroot=/home/

5. Restart your Apache server

debian-server# /etc/init.d/apache2 restart

Now test if mod_suphp is working on your Apache. We will test it through a tiny php script;
Paste the script to let’s say suphp.php

<? system( "id" ); ?>

Now if suphp is working you’ll see something like:
uid=1002(myuser) gid=1002(myuser) groups=1002(myuser)
instead of the default;
uid=33(www-data) gid=33(www-data) groups=32(www-data)

Now there are a few more drawbacks with SuPHP which I feel obliged to discuss.
On the first place suphp will excecute through php5-cgi and therefore the script execution
should be considered a way slower comparing to the default mod_php5.
I cannot precisely tell how much slower would be php script execution compared to mod_php5 but I
pressume at least 10 to 20% of the usual performance will be gone.
One of the possible ways to speed-up php execution in that case is to use mod_fastcgi.

Installing a new server

Friday, October 19th, 2007

On monday I was in Varna to install a new server. The old one is a P3 450 Mhz 320 MB of RAMsince the developers work on the samba the machine is heavy loaded and the collegues’s workis being often interrupted waiting for files to save on the machine etc.The new server is a 2 CPU Xeon (3.2 Ghz), pretty neat box. It took me 2 days to configurethe machine because I experienced problems with the Hardware (Motherboard included VIA RAID 6410).I prayed God to bless me be able to make the machine and ofcourse it happened. Since Wednesdaythe new server works smoothly. It’s running SAMBA, Apache, MySQL and some routine backupping scriptsetc. Actually I ended installing a software RAID, VIA seems to have support only for 2.4.x kernels.I was thinking about installing FreeBSD but eventually I ended with Debian 4.0.Today I had to configure some Squid ACLs because the boss wanted to filter some job recruitmentsites for the users in the office. Also I installed the ipp2p kernel module on the Internet Gatewayto drop all torrent based traffic. I had to make one redirect from 10.10.10.1:80 -> 10.10.10.2:80 I thoughtabout the classical way to redirect port but it didn’t worked after some investigation and helpfrom the people on irc.freenode.net #iptables I figured out If you have to redirect ports on thesame subnet then you have to have also one more SNAT ruleEND—–

Installing hardware RAID monitor on IBM xseries 345 model 8670, IBM Server RAID monitoring via IBM’s RAID software RaidMan on 32 bit (i386) Debian Etch

Friday, October 16th, 2009

Following my prescriptions the company where I work for has bought two hard drives for one of the servers we use for website hosting. The two drives are with capacity of 80GB.

Yesterday I spend part of the day communicating with the tech support in the colocation center in (Evolink) Sofia Thanks God the hardware raid building has been succesfully managed by one of my colleagues working in Evolink.
However he mentioned that some kind of warnings were present in the previous existing RAID 1 array.
To be honest I’ve never thought before about monitoring the RAID array, before the tech support guy suggested to check the warning messages the raid array issues.

To build the hardware array during boot, (Kalin), that’s how the technical support in Evolink is called, he had to download the cd with software for our IBM xseries 8670, and then boot up from the cd
following the instructions in the Server manual to build the array. Anyways that obviously went smoothly as I already mentioned. Taking in consideration his suggestions for monitoring the drives in the RAID array.

I did some research in Google and came across the following Ubuntu’s forums thread Monitoring utility for IBM ServerRAID .
The thread dealt with converting the original RPM package bundled on the IBM software original CD to a deb package in order to make it properly installable and integrated into debian based systems (debian, ubuntu).

Since our current OS of choice on the IBM server is Debian Etch linux, I had the follow the part in the Article from the post dealing with 32 bit rpm package conversion. Everything explained in the forum worked out-of-the-box happily, no settle backs occured. Thus I’ll present the steps here literally required to be partaked to achieve
the proper install of IBM’s hardware monitoring software:

1. Download the IBM ServerRAID application CD from IBM Support's Website
Link to the ISO at the time of writting this post can be obtained from IBM ServerRAID application CD ,

just make sure you use a browser and accept the license agreement before the download proceeds
2. Install the following 3 packages,
# apt-get install alien fakeroot libstdc++5

3. link sort required, cause in Redhat sort is located on a different place
# ln -s /usr/bin/sort /bin/sort

4.Mount the downloaded iso
# mount -o loop ibm_sw_srapp_9.00-16973_anyos_32-64.iso /media/cdrom

5. Copy rpm to /some/directory and convert it to .deb package
# cp /media/cdrom/linux/manager/RaidMan-9.00.i386.rpm /some/directory
# cd /some/directory
# fakeroot alien -c RaidMan-9.00.i386.rpm
Next tweak some scripts to make it Debian/Ubuntu native

6.
# mkdir -p raidman_9.00-1_i386/DEBIAN

7.
# dpkg -x raidman_9.00-1_i386.deb raidman_9.00-1_i386/

8.
# dpkg -e raidman_9.00-1_i386.deb raidman_9.00-1_i386/DEBIAN

9.
# vim raidman_9.00-1_i386/DEBIAN/postinst

10.
# (remove the line containing “chkconfig –add raid_agent”
Next open:
# vim raidman_9.00-1_i386/DEBIAN/postrm
# chkconfig –del raid_agent

11.
# dpkg -b raidman_9.00-1_i386/ raidman_9.00-1_i386.deb
12. Now install the new .deb raidman package
# dpkg -i raidman_9.00-1_i386.deb

13. With God’s help everything should go smoothly and now you should have
a working raid monitoring software on your Debian Server
To start the raid agent issue the command:

# /etc/init.d/raid_agent start

Here is also a download link to raidman_9.00-1_i386.deb