Monday 29 July 2013

Automated ClamAV Virus Scanning

Automating Linux Anti-Virus Using ClamAV and Cron

Thankfully Linux isn’t a platform which has a significant problem with Viruses, however it is always better to be safe than sorry. Luckily ClamAV is an excellent free anti-virus solution for Linux servers. However, at least on CentOS 6.x the default install doesn’t offer any automated scanning and alerting. So here is what I’ve done:

The following steps assume you are using RHEL5, but should apply to other Linux distributions as well.

First, you’ll want to install ClamAV:












yum install clamav clamav-db clamd

/etc/init.d/clamd start




On RHEL5 at least this automatically sets up a daily cron job that uses freshclam to update the virus definitions, so that’s good.

Next I recommend removing the test virus files, although you can save this until after you test the rest of the setup:










rm -rf /usr/share/doc/clamav-0.95.3/test/




Now we want to setup our automation. I have a daily cron job that scans the entire server which can take several minutes, and then an hourly cron job that only scans files which were created or modified within the last hour. This should provide rapid notification of any infection without bogging your server down for 5 minutes every hour. The hourly scans run in a couple of seconds.

Each scanning script then checks the scan logs to see if there were any infected files found, and if so immediately sends you a notification e-mail (you could set this address to your mobile phone’s SMS account if you wanted).

The Daily Scan:












#vi /etc/cron.daily/clamscan_daily




Paste in:










1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29


#!/bin/bash


# email subject

SUBJECT="VIRUS DETECTED ON `hostname`!!!"

# Email To ?

EMAIL="me@domain.com"

# Log location

LOG=/var/log/clamav/scan.log


check_scan () {


    # Check the last set of results. If there are any "Infected" counts that aren't zero, we have a problem.

    if [ `tail -n 12 ${LOG}  | grep Infected | grep -v 0 | wc -l` != 0 ]

    then

        EMAILMESSAGE=`mktemp /tmp/virus-alert.XXXXX`

        echo "To: ${EMAIL}" >>  ${EMAILMESSAGE}

        echo "From: alert@domain.com" >>  ${EMAILMESSAGE}

        echo "Subject: ${SUBJECT}" >>  ${EMAILMESSAGE}

        echo "Importance: High" >> ${EMAILMESSAGE}

        echo "X-Priority: 1" >> ${EMAILMESSAGE}

        echo "`tail -n 50 ${LOG}`" >> ${EMAILMESSAGE}

        sendmail -t < ${EMAILMESSAGE}

    fi


}


clamscan -r / --exclude-dir=/sys/ --quiet --infected --log=${LOG}


check_scan














# chmod +x /etc/cron.daily/clamscan_daily




The Hourly Scan:












# vi /etc/cron.hourly/clamscan_hourly




Paste in:










1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31


#!/bin/bash


# email subject

SUBJECT="VIRUS DETECTED ON `hostname`!!!"

# Email To ?

EMAIL="me@domain.com"

# Log location

LOG=/var/log/clamav/scan.log


check_scan () {


    # Check the last set of results. If there are any "Infected" counts that aren't zero, we have a problem.

    if [ `tail -n 12 ${LOG}  | grep Infected | grep -v 0 | wc -l` != 0 ]

    then

        EMAILMESSAGE=`mktemp /tmp/virus-alert.XXXXX`

        echo "To: ${EMAIL}" >>  ${EMAILMESSAGE}

        echo "From: alert@domain.com" >>  ${EMAILMESSAGE}

        echo "Subject: ${SUBJECT}" >>  ${EMAILMESSAGE}

        echo "Importance: High" >> ${EMAILMESSAGE}

        echo "X-Priority: 1" >> ${EMAILMESSAGE}

        echo "`tail -n 50 ${LOG}`" >> ${EMAILMESSAGE}

        sendmail -t < ${EMAILMESSAGE}

    fi


}


find / -not -wholename '/sys/*' -and -not -wholename '/proc/*' -mmin -61 -type f -print0 | xargs -0 -r clamscan --exclude-dir=/proc/ --exclude-dir=/sys/ --quiet --infected --log=${LOG}

check_scan


find / -not -wholename '/sys/*' -and -not -wholename '/proc/*' -cmin -61 -type f -print0 | xargs -0 -r clamscan --exclude-dir=/proc/ --exclude-dir=/sys/ --quiet --infected --log=${LOG}

check_scan














chmod +x /etc/cron.hourly/clamscan_hourly




Protected System


You should now have a well protected system with low impact to system performance and rapid alerting. Anti-Virus is only one piece of protecting a server, but hopefully this makes it easy to implement for everyone.

Fixing Reverse DNS

Fixing your Revers DNS (RDNS)


One of the big problems with email these days is spam and to fight spam many services like us at Junk Email Filter rely on Reverse DNS to get information about the IP address of the email server that is trying to connect to us. If we can't read your reverse DNS your email will probably get through but if you have any other problem in addition to bad RDNS then your email might get blocked or delayed. And neither you or us want that to happen.

As we all know reverse DNS is tricky and if you are reading this you might have a problem you need to solve. You might think your reverse DNS is right but it might not be. There are two things you need to get right in order for RDNS to work correctly. You need:

  1. A PTR record that returns a NAME for the IP address that is being looked up.

  2. The name that is looked up must resolve back to the same IP address. The goal is:


IP -> NAME
NAME -> IP

Often the second one is done improperly causing the RDNS to fail.

For example. suppose your IP address is 69.50.231.166. Running dig (a Linux command line utility) returns:
dig -x 69.50.231.166

;; ANSWER SECTION:
166.231.50.69.in-addr.arpa. 1019 IN PTR smtp166.junkemailfilter.com.

This is correct. Now we look up smtp166.junkemailfilter.com
dig smtp166.junkemailfilter.com

;; ANSWER SECTION:
smtp166.junkemailfilter.com. 7200 IN A 69.50.231.166

You'll notice that it resolves back to the same IP address. This is very important because it prevents other's from spoofing your domain.
69.50.231.166 -> smtp166.junkemailfilter.com
smtp166.junkemailfilter.com -> 69.50.231.166

 

Testing your Reverse DNS


You can check the reverse DNS of an IP address here.

Common Mistakes


Many people think their RDNS is correct but they make common mistakes such as:

  1. The name returned resolves to a different IP address than the original.

  2. The name returned doesn't resolver to anything.


For example, suppose your IP is 9.9.9.9 and you set the PTR record to return mail.mydomain.com. When someone looks up the RNDS for 9.9.9.9 they get mail.mydomain.com. But when they look up mail.mydomain.com it returns 8.8.8.8 which is not 9.9.9.9, or even worse, the name doesn't resolve at all.

To fix the problem you would have to make sure that mail.mydoimain.com resolves to 9.9.9.9.

If you make these changes and you get it right then you will have a much easier time not only delivering email to us but also to thousands of other email servers that have the same issues we do. We hope this information is helpful in resolving your RDNS problem.

Saturday 27 July 2013

MySQL Through SSH Tunnel

Below is my way of connecting to a remote MySQL server via an SSH tunnel. Fairly self explanatory but I can never quite remember the exact format for SSH tunnels.
ssh -f -L 3307:127.0.0.1:3306 <USER>@<HOST> sleep 20; mysql -h 127.0.0.1 -P 3307 -u<USER> -p <DB>

The sleep command gives it enough time to connect otherwise it would fail. Dirty, but I like it.

rsync Bandwidth Limit

It’s the –bwlimit switch. For example:

rsync -avz /home/user/Music foo@bar.com:/dest/to/new/folder --bwlimit=2000

The bwlimit switch is in Kb/s

Friday 26 July 2013

Pointing MX address to another server with cPanel without domain name

Lets say you have a client who have a website hosted with cPanel. But one day the client requests to point his mail exchange to their mail server. He only give you the IP address, without domain name.

Technically, you cannot point a MX address using only IP hostname, you must use a domain name. But in my case, I only have IP address. Here is how.

Using WHM, go to Edit DNS Zones menu. Choose your desired domain.

You will see a record :

sert.com.     14400     IN      MX     0     sert.com.
mail             14400     IN      CNAME sert.com.

Convert this record to :

sert.com.     14400     IN     MX     0      mail.sert.com.
mail             14400     IN     A     192.168.0.1

Change 192.168.0.1 with the IP the client give to you.

Click save settings, then try by yourself to ping mail.sert.com. If the mail.sert.com ping result still pointing to old IP address, clear your DNS cache. Here is how to clear DNS cache in all OSes.

If still not pointing to new, check your settings. Note all changes need max 48 hour to propagate to servers.

Tuesday 23 July 2013

Setting up email piping

Mail Transfer Agent


A mail transfer agent (MTA) or mail relay is a software that transfers electronic mail messages from one computer to another using a client-server application architecture. An MTA implements both the client (sending) and server (receiving) portions of the Simple Mail Transfer Protocol. MTAs receive e-mail messages and recipient addresses from local users, remote hosts and deliver the messages to their destinations. Popular MTA available used on servers are exim, qmail, sendmail and postfix.

The MTAs are integral part of Messaging system. A message transfer agent receives mail from either another MTA or a MUA (Mail User Agent). The transmission details are specified by the Simple Mail Transfer Protocol (SMTP). When a recipient mailbox of a message is not hosted locally, the message is relayed, that is, forwarded to another MTA. Every time an MTA receives an email message, it adds a Received trace header field to the top of the header of the message, thereby building a sequential record of MTAs handling the message. The process of choosing a target MTA for the next hop is also described in SMTP, but can usually be overridden by configuring the MTA software with specific routes.

Prerequisites for email piping


There are some prerequisites that needs to be fulfilled before configuring email piping on the server:

The first and the most important is that, the mail server must be installed on the same Linux server on which the helpdesk is installed.








Kayako does not support email piping on Windows server.


Once the first prerequisite is met, the others follow:

The email address setup as email queue should be a virtual email address without any inbox associated with it.

The permissions of 755 should be set on the path leading to "/../console/index.php/" file.

PHP interpreter path: By default the path for PHP interpreter in the '/../console/index.php' file is set as '/usr/bin/php'. This is the path of PHP executable file that is used by mail parser script to process the emails coming to the Piped email address. If the path of the PHP interpreter is different than the default one specified in file, you will need to edit the '/../console/index.php' file accordingly.  The path of the PHP interpreter can be found on the server by the following command:












#which php








Per the output mentioned in the image, the PHP interpreter's path in the 'console/index.php' file of the help desk needs to be edited to as '/usr/local/bin/php'.

Setting up e-mail piping on different MTAs


An e-mail queue can be created which can handle e-mails that are piped into the system. Email piping is the automatic pushing of an e-mail by the server into the helpdesk installation files. This is done by forwarding an e-mail alias to a script within the helpdesk installation. The setting up of email aliases may vary depending upon the MTA being used on the server. Every MTA support email aliasing. As the email are aliased to a helpdesk script, the full path to the script must be executable by others. This does not open up any security hole on the server. The path to PHP binary may require to be modified according to location of PHP binary on the server. The issue will be discussed in On-The-Floor session under Email Piping.

Email piping in Qmail


This procedure explains how to set up e-mail piping in Qmail.

  • Via SSH, we need to manually edit the file /var/qmail/mailnames/company.com/.qmail-support, where support is the e-mail alias name (support@yourdomain.com). The .qmail-support is the name of the file we are editing, and in it we will place the pipe command.














| /home/httpd/vhosts/company.com/httpdocs/full/path/to/console/index.php







  • This command will pipe incoming e-mails to the specified location. Save the file.


Setting up e-mail piping in Sendmail


This procedure explains how to set up e-mail piping manually using the Sendmail mail transport system:

  • Open the aliases (/etc/aliases) file for editing.

  • Assuming that we creating aliases for the e-mail addresses support@company.com and services@company.com, we will create the corresponding entries in the aliases file as follows:














support: | /full/path/to/console/index.php

sales:   | /full/path/to/console/index.php






Now we must ensure we have created an e-mail queue within the administrator control panel, so that the mail parser will accept the incoming e-mail messages. If we are still facing the issue with email piping, check the SMRSH restrictions.

SMRSH Restrictions: Certain Sendmail systems are configured with Sendmail Restricted Shell enabled to prevent the execution of any malicious programs or scripts. If we receive a bounce message with detailing a SMRSH failure, then we will need to configure the mail parser with SMRSH in the following way:

  • Find the SMRSH path, run the command man smrsh as shown below.

  • The path to SMRSH is listed in the second paragraph. Through the information displayed after executing this command, we now know that SMRSH files should go under "/etc/smrsh".

  • We will now need to create a symlink to our "/console/index.php" under the directory "/etc/smrsh".


The command syntax is:












ln -s /full/path/to/console/index.php /etc/smrsh/index.php







  • Once the symlink has been created, we should change the alias file contents as follows:














From: support: | /full/path/to/console/index.php

To:   support: | /etc/smrsh/index.php







  • Once the aliases file has been edited and saved, we will need to execute the newaliases command.


Setting up e-mail piping in Postfix


This procedure explains how to set up e-mail piping manually using the Postfix mail transport system.

  • Open the /etc/postfix/aliases file for editing.

  • Assuming that we are creating aliases for the e-mail addresses sales@company.com and support@company.com, we will create the corresponding entries in the aliases file as follows:














support: | /full/path/to/console/index.php

sales:   | /full/path/to/console/index.php







  • Once the aliases file has been edited and saved, we will need to execute the newaliases command.


Setting up e-mail piping in Exim


This procedure explains how to set up e-mail piping manually using the EXIM mail transport system.

  • Open the /etc/valiases/company.com file for editing.

  • Assuming that we are creating aliases for the e-mail addresses sales@company.com and support@company.com, we will create the corresponding entries in the aliases file as follows:














support: | /full/path/to/console/index.php

sales:   | /full/path/to/console/index.php







  • Once the aliases file has been edited and saved, we will need to execute the newaliases command.


Setting up e-mail piping in cPanel


Many hosting providers use cPanel as their control panel. They allow limited access to users so that the users may manage their domain from graphical interface.

  • Login to your cPanel control panel.

  • From the main menu, select the Mail icon and choose the Forwarder option.




  • Click on Add Forwarder to create a new forwarder.




  • You will be presented with a series of fields that will allow you to forward an e-mail alias (an alias being the “support” in the e-mail address “support@yourdomain.com”.




  • In the Address to Forward field, enter the e-mail alias. If you wish to create an e-mail forwarder for the address support@yourdomain.com, the alias here should be support.

  • In the Pipe to a Program, enter the location to which you want to forward the incoming mail to. This location has to be the pipe command to the absolute path of the location of your ../console/index.php file (the file that accepts incoming e-mail pipes). This will pipe incoming e-mails to the specified location.

Monday 22 July 2013

Linux / Unix: Find Inode Of a File Command

ls Command: Display Inode


$ ls -li filename
$ ls -li /etc/resolv.conf

Sample outputs:
25766494 -rwxr-xr-x 1 root root 332 May 5 14:14 /etc/resolv.conf
25766494 is inode number and the -i option displays the index number (inode) of /etc/resolv.conf file.

stat Command: Display Inode


You can also use the stat command as follows:
$ stat fileName-Here
$ stat /etc/passwd

Sample outputs:
  File: `/etc/passwd'
Size: 1644 Blocks: 8 IO Block: 4096 regular file
Device: fe01h/65025d Inode: 25766495 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2012-05-05 16:29:42.000000000 +0530
Modify: 2012-05-05 16:29:20.000000000 +0530
Change: 2012-05-05 16:29:21.000000000 +0530

Wednesday 10 July 2013

Find spam script location with Exim

Locate top scripts sending into Exim



Using the steps below I'll show you how to locate the top scripts on your server that send out email. You can then search the Exim mail log for those scripts to determine if it looks like spam, and even check your Apache access logs in order to find how a spammer might be using your scripts to send out spam.




  • Login to your server via SSH as the root user.




  • Run the following command to pull the most used mailing script's location from the Exim maillog:



grep cwd /var/log/exim_mainlog | grep -v /var/spool | awk -F”cwd=” '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n



Code breakdown:






















grep cwd /var/log/exim_mainlogUse the grep command to locate mentions of cwd from the Exim mail log. This stands for current working directory.
grep -v /var/spoolUse the grep with the -v flag which is an invert match, so we don't show any lines that start with /var/spool as these are normal Exim deliveries not sent in from a script.
awk -F"cwd=" '{print $2}' | awk '{print $1}'Use the awk command with the -Field seperator set to cwd=, then just print out the $2nd set of data, finally pipe that to the awk command again only printing out the $1st column so that we only get back the script path.
sort | uniq -c | sort -nSort the script paths by their name, uniquely count them, then sort them again numerically from lowest to highest.


You should get back something like this:



15 /home/userna5/public_html/about-us
25 /home/userna5/public_html
7866 /home/userna5/public_html/data



Here we can see that the /home/userna5/public_html/data directory by far has more deliveries coming in than any others.




  • Now we can run the following command to see what scripts are located in that directory:



ls -lahtr /userna5/public_html/data



In thise case we got back:



drwxr-xr-x 17 userna5 userna5 4.0K Jan 20 10:25 ../
-rw-r--r-- 1 userna5 userna5 5.6K Jan 20 11:27 mailer.php
drwxr-xr-x 2 userna5 userna5 4.0K Jan 20 11:27 ./



So we can see there is a script called mailer.php in this directory




  • Knowing the mailer.php script was sending mail into Exim, we can now take a look at our Apache access log to see what IP addresses are accessing this script using the following command:



grep "mailer.php" /home/userna5/access-logs/example.com | awk '{print $1}' | sort -n | uniq -c | sort -n



You should get back something similar to this:



2 123.123.123.126
2 123.123.123.125
2 123.123.123.124
7860 123.123.123.123



So we can clearly see that the IP address 123.123.123.123 was responsible for using our mailer script in a malicious nature.




  • If you did find a malicous IP address sending out a large volume of messages from a script on your server you'll probably want to go ahead and block them at your server's firewall so that they can't try to connect again. This can be accomplished with the following command:



apf -d 123.123.123.123 "Spamming from script in /home/userna5/public_html/data"



You should now have learned how to use your server's Exim mail log to see what scripts on your server are causing the most email activity, and also how to investigate to see if any of them are malicious in nature trying to send out spam from your server.

Wednesday 3 July 2013

How to check Inodes Usage on cPanel Server

Solution ::-
For dedicated  and VPS server, you can check the inodes of an account by  using SSH.
root@servertech [~]# quota -s  cPanel username

Also, you can check the details of  inodes Usage for a specific user or folder via ssh using the below command.
root@servertech [~]#  echo "Inode usage for: $(pwd)" ; for d in `find -maxdepth 1 -type d |cut -d/ -f2 |grep -xv . |sort`; do c=$(find $d |wc -l) ; printf "$ctt- $dn" ; done ; printf "Total: tt$(find $(pwd) | wc -l)n"

To check the whole home partition Inodes Usage using the below command.
root@servertech [~]# find /home -maxdepth 1 -type d | while read -r dir; do printf "%s:t" "$dir"; find "$dir" | wc -l; done