Posts Tagged ‘logs’

Linux PHP Disable chmod() and chown() functions for better Apache server security

Monday, July 15th, 2013

php_tighten_security_by_enabling_safe_mode-php-ini-function-prevent-crackers-break-in-your-server
I have to administer few inherited Linux servers with Ubuntu and Debian Linux. The servers hosts mainly websites with regularly un-updated Joomlas and some custom developed websites which were developed pretty unsecure. To mitigate hacked websites I already disabled some of most insecure functions like system(); eval etc. – I followed literally my previous tutorial PHP Webhosting security disable exec();, system();, open(); and eval();
Still in logs I see shits like:
 

[error] [client 66.249.72.100] PHP Warning:  mkdir(): No such file or directory in /var/www/site/plugins/system/jfdatabase/intercept.jdatabasemysql.php on line 161

Hence to prevent PHP mkdir(); and chown(); functiosn being active, I had to turn on in /etc/php5/apache2/php.ini – safe_mode . For some reason whoever configured Apache leave it off.

safe_mode = on

Hopefully by disabling this functions will keep cracker bot scripts to not create some weird directory structures on HDD or use it as mean to DoS overflow servers filesystem.

Hope this help others stabilize their servers too. Enjoy ! 🙂

Fixing Clamav error: “WARNING: Can’t download daily.cvd from database.clamav.net”

Thursday, June 6th, 2013

On one of the Debian Squeeze Servers, where I have Running QMAIL Server, I haven't checked logs for a long time. Cause Qmail is configured and all runs smoothly. Just today while checking logs, I've noticed in /var/log/clamav/clamav.log, clamav database fails to be updated with an error, e.g.:

qmail:~# tail -n 28 /var/log/clamav/clamav.log

ClamAV update process started at Thu Jun 6 20:47:14 2013
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
WARNING: getpatch: Can't download daily-16682.cdiff from db.local.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from db.local.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from db.local.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from db.local.clamav.net
ERROR: getpatch: Can't download daily-16682.cdiff from db.local.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
ERROR: Can't download daily.cvd from db.local.clamav.net
Giving up on db.local.clamav.net…
ClamAV update process started at Thu Jun 6 20:47:15 2013
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
WARNING: Can't download daily.cvd from database.clamav.net
Trying again in 5 secs…
ClamAV update process started at Thu Jun 6 20:47:20 2013
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
WARNING: Can't download daily.cvd from database.clamav.net

On host Freshclam is configured to run in background as a service i.e.:

qmail:~#
 ps ax|grep -i fresh|grep -v grep
13615 ? Ss 0:02 /usr/bin/freshclam -d –quiet
 

I stopped clamav and tried running it manually through its script: qmail:~# /etc/init.d/clamav-freshclam restart

The error was reoccuring, so I decided to kill it and try running freshclam manually:

qmail:~# kill -9 freshclam

qmail:~# freshclam
I got same error again:
 

Thu Jun 6 16:46:20 2013 -> ClamAV update process started at Thu Jun 6 16:46:20 2013 Thu Jun 6 16:46:20 2013 -> main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven) Thu Jun 6 16:46:20 2013 -> WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net Thu Jun 6 16:46:20 2013 -> WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net Thu Jun 6 16:46:20 2013 -> WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net Thu Jun 6 16:46:20 2013 -> WARNING: getpatch: Can't download daily-16682.cdiff from database.clamav.net Thu Jun 6 16:46:20 2013 -> ERROR: getpatch: Can't download daily-16682.cdiff from database.clamav.net Thu Jun 6 16:46:20 2013 -> WARNING: Incremental update failed, trying to download daily.cvd Thu Jun 6 16:46:20 2013 -> ERROR: Can't download daily.cvd from database.clamav.net Thu Jun 6 16:46:20 2013 -> Giving up on database.clamav.net… Thu Jun 6 16:46:20 2013 -> Update failed. Your network may be down or none of the mirrors listed in /etc/clamav/freshclam.conf is working. Check http://www.clamav.net/support/mirror-problem for possible reasons.

The solution was to delete clamav database filedaily.cvd and then run another freshclam Clamav DB virus update:

qmail:~# rm -f /var/lib/clamav/daily.cvd
qmail:~# freshclam
root@pcfreak:/etc/init.d# freshclam ClamAV update process started at Thu Jun 6 22:07:21 2013
main.cvd is up to date (version: 54, sigs: 1044387, f-level: 60, builder: sven)
Downloading daily.cvd [100%]
daily.cvd updated (version: 17309, sigs: 1302714, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 214, sigs: 41, f-level: 63, builder: neo)
Database updated (2347142 signatures) from db.local.clamav.net (IP: 195.222.33.229)

Finally, to make freshclam work as daemon, restarted init script:

qmail:~# /etc/init.d/clamav-freshclam restart
[ ok ] Stopping ClamAV virus database updater: freshclam.
[ ok ] Starting ClamAV virus database updater: freshclam.

 

swap_pager_getswapspace: failed, MySQL troubles on FreeBSD 7.2 cause and solution

Tuesday, May 3rd, 2011

Every now and then my FreeBSD router dmesg ( /var/log/dmesg.today ) logs, gets filled with error messages like:

pid 86369 (httpd), uid 80, was killed: out of swap space
swap_pager_getswapspace(14): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(11): failed
swap_pager_getswapspace(12): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(14): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(8): failed

Using swapinfo during the swap_pager_getswapspace(16): failed messages were logged in, I figured out that definitely the swap memory over-use is the bottleneck for the troubles, to find this I used the command:

freebsd# swapinfo
Device 1K-blocks Used Avail Capacity Type
/dev/ad0s1b 49712 45920 3792 92% Interleaved

After some investigation, I’ve figured out that the MySQL server is causing the kernel exceeded swap troubles.

My current MySQL server version is installed from the ports tree, whether I’m using the bsd port /usr/ports/databases/mysql51-server/ and it appears to work just fine.

However I have noticed that the mysql-server is missing a my.cnf file!, which means the mysql server is running under a mode with some kind of default configurations.

Strangely in the system process list it appeared it is using a default my.cnf file located in /var/db/mysql/my.cnf

Below you see the paste from the ps command:

ps axuww freebsd# ps axuww | grep -i my.cnf | grep -v grep
mysql 7557 0.0 0.1 3464 1268 p1 I 12:03PM 0:00.01 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --pid-file=/var/db/mysql/pcfreak.pidmysql 7589 0.0 5.1 93284 52852 p1 I 12:03PM 0:59.01 /usr/local/libexec/mysqld --defaults-extra-file=/var/db/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql --user=mysql --pid-file=/var/db/mysql/pcfreak.pid --port=3306 --socket=/tmp/mysql.sock

Nevertheless it appeared the sql server is running the file /var/db/mysql/my.cnf conf was not existing! This was really weird for me as I’m used to have the default my.cnf from my previous experience with Linux servers!

Thus the next logical thing I did was to create my.cnf conf file in order to be able to have a proper limiting configuration for the sql server.

The FreeBSD my.cnf skele files are found in /usr/local/share/mysql/, here are the 4 files one can use as a starting basis for further configuration of the mysql-server.

freebsd# ls -al /usr/local/share/mysql/my-*.cnf
-r--r--r-- 1 root wheel 4948 Aug 12 2009 /usr/local/share/mysql/my-huge.cnf
-r--r--r-- 1 root wheel 20949 Aug 12 2009 /usr/local/share/mysql/my-innodb-heavy-4G.cnf
-r--r--r-- 1 root wheel 4924 Aug 12 2009 /usr/local/share/mysql/my-large.cnf
-r--r--r-- 1 root wheel 4931 Aug 12 2009 /usr/local/share/mysql/my-medium.cnf
-r--r--r-- 1 root wheel 2502 Aug 12 2009 /usr/local/share/mysql/my-small.cnf

I have chosen to use the my-medium.cnf as a skele to tune up, as my server is not high iron one e.g. the host I run the mysql is a (simple dual core 1.2Ghz system).

Further on I copied the /usr/local/share/mysql/my-medium.cnf to /var/db/mysql/my.cnf e.g.:

freebsd# cp -rpf /usr/local/share/mysql/my-medium.cnf /var/db/mysql/my.cnf

As a next step to properly tune up the default values of the newly copied my.cnf to my specific server I used the Tuning-Primer MySQL tuning script

Using tuning-primer.sh is really easy as all I did is download, launch it and follow the script suggestions to correct some of the values already in my.cnf

I have finally ended up with the following my.cnf after using tuning-primer.sh to optimize mysql server to work with my bsd host

Now I really hope the shitty swap_pager_getswapspace: failed errors would not haunt me once again by crashing my server and causing mem overheads.

Still I wonder why the port developer Alex Dupre – ale@FreeBSD.org choose not to provide the default mysql51-server conf with some kind of my.cnf file? I hope he had a good reason.

Recommended logrorate practices on heavy loaded (busy) Apache Linux servers

Wednesday, March 7th, 2012

Apache logrotate Debian good configuration for heavy loaded servers

If you are sys admin of Apache Webserver running on Debian Linux relying on logrorate to rorate logs, you might want to change the default way logroration is done.

Little changes in the way Apache log files are served on busy servers can have positive outcomes on the overall way the server CPU units burden. A good logrotation strategy can also prevent your server from occasional extra overheads or downtimes.

The way Debian GNU / Linux process logs is well planned for small servers, however the default logroration Apache routine doesn't fit well for servers which process millions of client requests each day.

I happen to administrate, few servers which are constantly under a heavy load and have occasionally overload troubles because of Debian's logrorate default mechanism.

To cope with the situation I have made few modifications to /etc/logrorate.d/apache2 and decided to share it here hoping, this might help you too.

1. Rotate Apache acccess.log log file daily instead of weekly

On Debian Apache's logrorate script is in /etc/logrotate.d/apache2

The default file content will be like so like so:

debian:~# cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
weekly
missingok
rotate 52
size 1G
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then
/etc/init.d/apache2 reload > /dev/null
fi
endscript
}

To change the rotation from weekly to daily change:

weekly

to

#weekly

2. Disable access.log log file gzip compression

By default apache2 logrotate script is tuned ot make compression of rotated file (exmpl: copy access.log to access.log.1 and gzip it, copy access.log to access.log.2 and gzip it etc.). On servers where logs are many gigabytes, once logrotate initiates its scheduled work it will have to compress an enormous log record of apache requests. On very busy Apache servers from my experience, just for a day the log could grow up to approximately 8 / 10 Gigabytes.
I'm sure there are more busy servers out there, which log files are growing to over 100GB for just a single day.
Gzipping a 100GB file piece takes an enormous load on the CPU, as well as often takes long time. When this logrotation gzipping occurs at a moment where the servers CPU cores are already heavy loaded from Apache serving HTTP requests, Apache server becomes inaccessible to most of the clients.
Then for end clients various oddities are experienced, for example Apache dropped connection errors, webserver returning empty pages, or simply inability to respond to the client browser.
Sometimes as a result of the overload, even secure shell connection to SSHD to the server is impossible …

To prevent your server from this roration overloads remove logrorate's default access.log gzipping by commenting:

compress

to

#comment

3. Change maximum log roration by logrorate to be up to 30

By default logrorate is configured to create and keep up to 52 rotated and gzipped access.log files, changing this to a lower number is a good practice (in my view), in cases where log files grow daily to 10 or more GBs. Doing so will save a lot of disk space and reduce the chance the hard disk gets filled in because of the multiple rorated ungzipped enormous access.log files.

To tune the default keep max rorated logs to 30, change:

rotate 52

to rotate 30

The way logrorate's apache log processing on RHEL / CentOS Linux is working better on high load servers, by default on CentOS logrorate is not configured to do log gzipping at all.

Here is the default /etc/logrorate.d/httpd script for
CentOS release 5.6 (Final)

[hipo@centos httpd]$ cat /etc/logrotate.d/httpd /var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
endscript
}

 

Yesterday, Today, Tomorrow

Sunday, December 2nd, 2007

Yesterday I spend a lot of time outside with Lily. We went to the fountain we watched film at home. The film was called”Wild Hogs” it was supposed to be a fun commedy (only supposed to be). This week is going to be a taugh one.We have to present a project at Marketing Research.

I have to write a 600 words resume about International Enterprice,also we have to make a presentation in Culture. Today in the morning i was on a Liturgy again. God’s grace ishere ! The week passed without serious server issues (Thanks God). Today I checked some logs of one of the serversand I observed oddities there. I checked the crontab and I realized it’s because of a crontab. The dumped databaseis a HUGE one 2.6G (bzipped).

I asked in irc.freenode.net #mysql, and the guys there pointed me to a similar issuewhich was supposed to be an MySQL bug when dumping large database. Since the dumping databases were of a type MyISAMI ofcourse could have used mysqlhotcopy.

But in the end the solution to the problem was removing “–opt” option fromthe backup opts of mysqldump and passing “–skip-opt” to it (I suspect this would slow the dumping process a lot).But I don’t care it is much better (a slow dumping), than hanging the whole Webserver and interrupting the site’s visibilityover the Internet.

Btw I started playing Quake 2, it’s cool but a little annoying there are too many tunnels and veryoften after I kill most of the bad guys I spend a lot of time searching for keys and stuff .. :).END—–

How to disable nginx static requests access.log logging

Monday, March 5th, 2012

NGINX logo Static Content Serving Stop logging

One of the companies, where I'm employed runs nginx as a CDN (Content Delivery Network) server.
Actually nginx, today has become like a standard for delivering tremendous amounts of static content to clients.
The nginx, server load has recently increased with the number of requests, we have much more site visitors now.
Just recently I've noticed the log files are growing to enormous sizes and in reality this log files are not used at all.
As I've used disabling of web server logging as a way to improve Apache server performance in past time, I thought of implying the same little "trick" to improve the hardware utilization on the nginx server as well.

To disable logging, I proceeded and edit the /usr/local/nginx/conf/nginx.conf file, commenting inside every occurance of:

access_log /usr/local/nginx/logs/access.log main;

to

#access_log /usr/local/nginx/logs/access.log main;

Next, to load the new nginx.conf settings I did a restart:

nginx:~# killall -9 nginx; sleep 1; /etc/init.d/nginx start

I expected, this should be enough to disable completely access.log, browser request logins. Unfortunately /usr/local/nginx/logs/access.log was still displaying growing with:

nginx:~# tail -f /usr/local/nginx/logs/access.log

After a bit thorough reading of nginx.conf config rules, I've noticed there is a config directive:

access_log off;

Therefore to succesfully disable logging I had to edit config occurance of:

access_log /usr/local/nginx/logs/access.log main

to

After a bit thorough reading of nginx.conf config rules, I've noticed there is a config directive:

access_log off;

Therefore to succesfully disable logging I had to edit config occurance of:

access_log /usr/local/nginx/logs/access.log main

to

access_log /usr/local/nginx/logs/access.log main
access_log off;

Finally to load the new settings, which thanksfully this time worked, I did nginx restart:

nginx:~# killall -9 nginx; sleep 1; /etc/init.d/nginx start

And hooray! Thanks God, now nginx logging is disabled!

As a result, as expected the load avarage on the server reduced a bit 🙂

Filter messages in Qmail with unwanted words, get rid of the Viagra annoying spam with Qtrap

Sunday, September 4th, 2011

Drop qmail received mail containing banned / unwanted words to get rid of Viagra and Sex related spam

Recently the annoying Viagra spam has emerged again. Therefore I decided to clean up some of the mails received to one of the qmail servers to protect users emailbox from this viagra peril.

To do so I’ve remember about an old script which used to be part of qmailrocks.org qmail install, the script is called qtrap and is able to filter emails based on list of specific mail contained words.
Since qmailrocks.org is gone (down) for some time and its still available only on few mirrored locations which by the way are not too easy to find I decided to write a little post on how qtrap.sh could be integrated quick & easy with any Qmail + Vpopmail install out there.

Hereby I include the description for qtrap.sh given by the script author:

“qtrap.sh script is applied on a per domain basis and serves as a “bad word” scanner to catch any spam that Spamassassin may have missed. This filter serves as the last defense against SPAM before it arrived in your inbox. I like this filter because it helps to get rid of any SPAM that happens to make it by Spamassassin. Without any protection at all, my mailbox gets a shit ton of SPAM every day. Within the first 3 months I enacted the Qtrap filter, Qtrap logged over 9,000 deleted SPAM messages, none of which were legitimate e-mails. My keyboard’s delete key was very appreciated the extra rest.

Any emails that are scanned and contain a banned word will be automatically deleted and logged by the qtrap script. A whitelist feature now exists so that individual addresses or domains can be exempt from the qtrap scan.”

Now as one might have general idea on what the script does. Here is the step by step qtrap.sh integration;

1. Create necessery qtrap directory and logs and set proper permissions

If the vpopmail is installed in /home/vpopmail , issue the following commands.

debian:~# cd /home/vpopmail
debian:~# mkdir -p qtrap/logs
debian:/home/vpopmail/qtrap# cd qtrap
debian:/home/vpopmail/qtrap# wget https://www.pc-freak.net/files/qtrap.sh
...
debian:/home/vpopmail/qtrap# cd ~
debian:~# touch /home/vpopmail/qtrap/logs/qtrap.logdebian:~# chown -R vpopmail:vchkpw /home/vpopmail/qtrapdebian:~# chmod -R 755 /home/vpopmail/qtrap

On older qmail installations it could be vpopmail is installed in /var/vpopmail if that’s the case, link /var/vpopmail to /home/vpopmail and go back to step 1. To link:

debian:~# ln -sf /var/vpopmail/ /home/vpopmail

2. Edit qtrap.sh to whitelist email addresses and build a ban words list

a) Include the email addresses mail arriving from which would not be checked by qtrap.sh

Inside qtrap.sh in line 63, there is a shell function whitelist_check(), the function looks like so:

whitelist_check () {
case $WHITELIST in
address@somewhere.com|address@somewhereelse.com)
echo $SENDER found in whitelist on `date "+%D %H:%M:%S"` >> /home/vpopmail/qtrap/logs/qtrap.log
exit 0;;
*)
;;
esac
}

By default the script has just two sample mails which gets whitelisted this is the line reading:

address@somewhere.com|address@somewhereelse.com

The whitelisted emails should be separated with a pipe, thus to add two more sample emails to get whitelisted by script the line should be changed like:

address@somewhere.com|address@somewhereelse.com|hipod@mymailserver.com|hipo@gmail.com

In order to whitelist an entire domain let’s say yahoo.com add a line to the above code like:

address@somewhere.com|address@somewhereelse.com|hipod@mymailserver.com|hipo@gmail.com|*yahoo.com

b) Defining the bad words ban list, mails containing them should not be delivery by qmail

The function that does check for the ban word list inside the script is checkall();, below is a paste from the script function:

checkall () {
case $BANNED_WORDS in
porn|PORN|Sex|SEX)
printout $BANNED_WORDS
echo MESSAGE DROPPED from $SENDER because of $BANNED_WORDS on `date "+%D %H:%M:%S"` >> /home/vpopmail/qtrap/logs/qtrap.log
exit 99;;
*)
;;
esac
}

checkall(); is located on line 74 in qtrap.sh, the exact list of banned words which the script should look for is located on line 76, the default qtrap.sh filters only mails containing just 4 words, e.g.:

porn|PORN|Sex|SEX)

To add the Viagra and VIAGRA common spam words to the list, modify it and expand like so:

porn|PORN|Sex|SEX|viagra|Viagra)

The delimiter is again | , so proceed further and add any unwanted spam words that are not common for any legit mails.

3. Install qtrap.sh to process all emails delivered to vpopmail

If its necessery to install the dropping of mails based on word filtering only to a single vpopmail virtualdomain do it with cmd:

debian:~# cd /home/vpopmail/domains/yourdomain.com
debian:/home/vpopmail/domains/yourdomain.com# touch .qmail-default.new
debian:/home/vpopmail/domains/yourdomain.com# echo '| /home/vpopmail/qtrap/qtrap.sh' >> .qmail-default.new
debian:/home/vpopmail/domains/yourdomain.com# echo "| /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox" >> .qmail-default.new
debian:/home/vpopmail/domains/yourdomain.com# chown vpopmail:vchkpw .qmail-default.new
debian:/home/vpopmail/domains/yourdomain.com# cp -rpf .qmail-default .qmail-default.bak; mv .qmail-default.new .qmail-default
If however qtrap.sh needs to get installed for all existing vpopmail virtualdomains on the qmail server, issue a one liner bash script:

debian:~# cd /home/vpopmail/domains
debian:/var/vpopmail/domains# for i in *; do cd $i; echo "| /home/vpopmail/qtrap/qtrap.sh" >> $i/.qmail-default.new;
echo "| /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox" >> $i/.qmail-default.new;
chown vpopmail:vchkpw .qmail-default.new; mv .qmail-default .qmail-default.old; mv .qmail-default.new .qmail-default; cd ..; done

This for loop will add ‘| /home/vpopmail/qtrap/qtrap.sh’ to all .qmail-default for all vpopmail domains.

Afterwards the .qmail-default file should contain the following two lines:

| /home/vpopmail/qtrap/qtrap.sh
| /home/vpopmail/bin/vdelivermail '' delete

A very important thing here you should consider that adding some common words, as let’s say hello or mail etc. could easily drop almost all the emails the qmail hands in to vpopmail.

Caution!! Never ever implement common words in the list of words !!
Always make sure the banned words added to qtrap.sh are words that are never enter an everyday legit email.

Another thing to keep in mind is that qtrap.sh doesn’t make a copy of the received message ,though it can easily be modified to complete this task.
Any mail that matches the banned words list will be dropped and lost forever.

4. Check if qtrap.sh is working

To check, if qtrap is working send mail to some mailbox located on the qmail server containing inside subject or mail message body the unwanted word defined inside qtrap.sh.

The mail should not be received in the mailbox to which its sent, if qtrap is working moreover qtrap.sh should log it inside it’s log file:

debian:~# cat /home/vpopmail/qtrap/logs/qtrap.log
MESSAGE DROPPED from hipo@mytestmail.com because of viagra on 09/03/11 11:34:19
MESSAGE DROPPED from support@mymailserver.com because of Viagra on 09/03/11 11:39:29

If the qtrap.log contains records similar to the one above, and the mail matching the banned word is not delivered, qtrap.sh is properly configured. If any issues check in qmail logs, they should have a good pointer on what went wrong with qtrap.sh invokation.

Note that I’ve integrated qtrap.sh to custom qmail install running on Debian Lenny 5.0 GNU/Linux.
If I have time I’ll soon test if its working fine on the latest stable Debian Squeeze and will report here in comments.
If however someone is willing to test if the script works on Debian Squeeze 6.0 or have tested it already please drop a comment to report if it works fine.
qtrap.sh, is a bit oldish and is not written to work too optimal therefore on some heavy loaded mail servers it can create some extra load and a bit delay the mail delivery. Thus when implementang one needs to consider the downsides of putting it in.

Also I was thinking tt might be nice if the script is rewritten to read the ban words and whitelist mails from files instead of as it is now as the words are hard coded in the script.
If I have some free time, I’ll probably do this, though I’m not sure if this is a too good idea as this might have a negative performance impact on the script execution time, as each instance of the script invoked should do one more operation of reading a file storing the ban words.

Well that’s pretty much it, enjoy 😉

Cause and solution for Qmail sent error “Requested action aborted: error in processing Server replied: 451 qq temporary problem (#4.3.0)”

Friday, October 28th, 2011

One of the qmail servers I manage today has started returning strange errors in Squirrel webmail and via POP3/IMAP connections with Thunderbird.

What was rather strange is if the email doesn’t contain a link to a webpage or and attachment, e.g. mail consists of just plain text the mail was sent properly, if not however it failed to sent with an error message of:

Requested action aborted: error in processing Server replied: 451 qq temporary problem (#4.3.0)

After looking up in the logs and some quick search in Google, I come across some online threads reporting that the whole issues are caused by malfunction of the qmail-scanner.pl (script checking mail for viruses).

After a close examination on what is happening I found out /usr/sbin/clamd was not running at all?!
Then I remembered a bit earlier I applied some updates on the server with apt-get update && apt-get upgrade , some of the packages which were updated were exactly clamav-daemon and clamav-freshclam .
Hence, the reason for the error:

451 qq temporary problem (#4.3.0)

was pretty obvious qmail-scanner.pl which is using the clamd daemon to check incoming and outgoing mail for viruses failed to respond, so any mail which contained any content which needed to go through clamd for a check and returned back to qmail-scanner.pl did not make it and therefore qmail returned the weird error message.
Apparently for some reason apparently the earlier update of clamav-daemon failed to properly restart, the init script /etc/init.d/clamav-daemon .

Following fix was very simple all I had to do is launch clamav-daemon again:

linux:~# /etc/inid.d/clamav-daemon restart

Afterwards the error is gone and all mails worked just fine 😉

How to block IP address with pf on FreeBSD, NetBSD and OpenBSD

Wednesday, July 27th, 2011

Pf Firewall BSD logo

I’ve noticed some IPs which had a kind of too agressive behaviour towards my Apache webserver and thus decided to filter them out with the Firewall.
As the server is running FreeBSD and my firewall choise is bsd’s pf I added the following lines to my /etc/pf.conf to filter up the abiser IP:

table persist file "/etc/pf.blocked.ip.conf"
EXT_NIC="ml0" # interface connected to internet
block drop in log (all) quick on $EXT_NIC from to any
echo '123.123.123.123' >> /etc/pf.blocked.ip.conf

As you see I’m adding the malicious IP to /etc/pf.blocked.ip.conf, if I later decide to filter some other IPs I can add them up there and they will be loaded and filtered by pf on next pf restart.

Next I restarted my pf firewall definitions to make the newly added rules in pf.conf to load up.

freebsd# pfctl -d
freebsd# pfctl -e -f /etc/pf.conf

To show all IPs which will be inside the blockips filtering tables, later on I used:

pfctl -t blockips -T show

I can also later use pf to add later on new IPs to be blocked without bothering to restart the firewall with cmd:

freebsd# pfctl -t blockedips -T add 111.222.333.444

Deleting an IP is analogous and can be achieved with:

freebsd# pfctl -t blockedips -T delete 111.222.333.444

There are also logs stored about pf IP blocking as well as the other configured firewall rules in /var/log/pflog file.
Hope this is helpful to somebody.