Category Archives: Linux

Configure German Spamassassin Update Channel in Ubuntu

Spamassassin already ships with the nice feature of running automatic updates to its core rules by using sa-update. Customisation of this update process is not well documented though. So it will be described in this article.

At http://wiki.apache.org/spamassassin/CustomRulesets quite some additional channels are listed. As an example the configuration of the German Language Ruleset will be outlined.

The Spamassassin Channel is documented on that website and says:

Available at: SpamAssassin Channel: 70_zmi_german.cf.zmi.sa-update.dostech.net

In your local Spamassassin’s setup the update rules reside at /var/lib/spamassassin/{SA_VERSION_NUMBER}. There, you may want to add the new channel definition by introducing the according gpg-key as follows:

wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY
sa-update --import GPG.KEY

Now, a manual channel update for that particular channel can be run:

sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

In order to have the cron-triggered nightly sa-update-run also update the new channel, a hook for sa-update has to be defined in /etc/spamassassin/sa-update-hooks.d/. There, create a file called german-rules-updates with the following content:

#!/bin/sh
sa-update --channel 70_zmi_german.cf.zmi.sa-update.dostech.net  --gpgkey 856AA88A

The German rules should now be updated each day and become active thereafter.

Squid config with NCSA Authentication in Ubuntu

This article describes a quick and easy way to implement a web proxy with most basic user authentication. The authentication mechanism uses an NCSA-style htpasswd file, well known also for other basic authentication purposes. The proxy server in use will be Squid proxy.

To install the necessary software, this line will do:

aptitude install squid

Now, a new file containing usernames and password hashes needs to be created:

htpasswd -c /etc/squid/passwd USERNAME
chmod 400 /etc/squid/passwd && chown proxy /etc/squid/passwd

The file /etc/squid/squid.conf has to be modified. The following lines have to be uncommented while the first of them needs adjustment as to the whereabouts of the passwd file. By default it points to usr/etc/passwd but we want it to be /etc/squid/passwd:

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic casesensitive off

In the ACL section two lines have to be inserted. The ACL section can be found by searching for “# ACCESS CONTROLS“.

acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

In case you want Squid to not reveal your client’s real IP address in HTTP requests it forwards, the follow option has to be disabled:

forwarded_for off 

A restart of Squid’s daemon will activate the recent changes:

service squid restart 

Exim 4 and ClamAV Malware Scanning in Ubuntu

Although virus scanners are installed on virtually all regular client systems nowadays, it’s nice to have the mailserver pre-scanning mails for malware. This article describes the configuration of ClamAV in conjunction with Exim 4 in Ubuntu Linux.

Assuming a working Exim 4 environment, the fist step is to install the necessary ClamAV package:

aptitude install clamav-daemon

To tell Exim which anti-virus scanner to use, the file /etc/exim4/exim4.conf.template needs to be customized. The default config already brings the necessary lines. They just need to be adjusted and uncommented:

av_scanner = clamd:/var/run/clamav/clamd.ctl
[...]
deny
  malware = *
  message = This message was detected as possible malware ($malware_name).
warn
  message = X-Virus-Scanned: (${readsocket{/var/run/clamav/clamd.ctl}{VERSION}{2s}{}{AV Not running}})

In order for ClamAV to access the mail spool it has to become a member of Exim’s group:

usermod -a -G Debian-exim clamav && service clamav-daemon restart

Now, sending a testmail like the one from EICAR should give you the appropriate malware rejection.

Greylisting in Exim 4 with Greylistd on Ubuntu Linux

In this article the approach of greylisting as a protection against spam in Exim 4 is being described. The concepts of greylisting temporarily rejects mails at SMTP time. A regular MTA without spamming intent will try to send mail again after a certain period of time. The average trojan or worm on the other hand usually sends spam in waves. It will try to send its load only once and won’t try again later. This concept facilitates spam reduction to a huge extent.

Setting up greylisting in Ubuntu Linux using Exim 4 is a breeze. To work, it simply needs the following lines.

Firstly, the installation of the package greylistd:

aptitude install greylistd

To activate the new package in Exim’s configuration, the following command will do some magic:

greylistd-setup-exim4 add

The default configuration of greylistd is a bit too paranoid from my point of view. Therefore I adjust /etc/greylistd/config as follows (usually the last two existing entries in that file):

singlecheck = true
singleupdate = true

This has the effect that a domain that has already been verified won’t become greylisted again if a different user sends from that particular domain. Also, it enables for manual manipulation of the whitelist by just adding IPs of “good” MTAs.

The whitelist file that is supposed to be edited by admins resides at /etc/greylistd/whitelist-hosts. The predifined whitelist can be found at /var/lib/greylistd/whitelist-hosts.

Configure Spamassassin for Exim 4 in Ubuntu

This article describes the configuration of the spam scanner called spamassassin in conjunction with the MTA called Exim 4 in Ubuntu Linux (as of writing Ubuntu 11.10 is the most recent). Assuming an otherwise working Exim 4 setup, this document describes just the essential steps to a working spamscanner.

First, the necessary packages need to be installed:

aptitude install exim4-daemon-heavy sa-exim spamassassin

In /etc/default/spamassassin set the following lines:

ENABLED=1
CRON=1

The first option lets the spamassassin daemon start on boot. The second one defines that spamassassin’s rules become updated each night using a cron job.

In order to check if the first steps went ok, it’s time to start spamassassin the very first time:

service spamassassin start

To check if spamassassin runs smoothly on it’s dedicated port, this command helps:

lsof -i :783

Now in /etc/exim4/exim4.conf.template, insert the following lines in MAIN CONFIGURATION SETTINGS:

local_scan_path = /usr/lib/exim4/local_scan/sa-exim.so

To enable Exim’s spamassassin connector, the file /etc/exim4/sa-exim.conf has to be modified. Comment the following line in that file:

# SAEximRunCond: 0

In default setups, debugging is enabled. That will lead to huge log files. So for production use, changing the following line to zero is advised:

SAEximDebug: 0

The updated file /etc/exim4/exim4.conf.template becomes active by running the following line:

update-exim4.conf && service exim4 restart

For a basic protection, the MTA is now good to go.

Disable Multiarch in Ubuntu Oneiric 11.10

Since Ubuntu 11.10 multiarch support becomes set by default in new systems as well as in upgraded ones. This sounds like a nice feature, but it breaks one of my favorite tools: aptitude. As of now, aptitude can’t handle multiple arches of the same package and therefore runs wild when told to do any task.

The solution to this is to disable multiarch for the time being. This is done by the following command:

mv /etc/dpkg/dpkg.cfg.d/multiarch /etc/dpkg/dpkg.cfg.d/multiarch.backup && apt-get update

In case aptitude learns how to handle multiarch some day, it can be re-enabled by running the command the other way round.

Transmission daemon: remove finished torrents

In transmission-daemon, downloaded torrents stay listed as long as they are not manually removed. In order to get them flushed automatically, the following command run by cron can help:

transmission-remote -l | grep 100% | grep Done | \
awk '{print $1}' | xargs -n 1 -I % transmission-remote -t % -r

In order to add this to cron, the “%”-symbols have to be escaped with a leading slash like this:

*/5 * * * * /usr/bin/transmission-remote -l | grep 100\% | grep Done | awk '{print $1}' | xargs -n 1 -I \% /usr/bin/transmission-remote -t \% -r

FlexGet Installation in Ubuntu

This posts documents the installation of FlexGet in Ubuntu. It uses FlexGet v1.0r2301 and by the time of writing it is tested on Ubuntu 11.04.

There is no apt-package for FlexGet available yet. It has to be installed from PyPI. In order to prepare the necessary build environment the following packages have to be installed:

aptitude install python2.6 python-setuptools

The next line downloads and builds FlexGet itself:

easy_install flexget

The following step is optional. In case an interface to transmission-daemon is of use, the according FlexGet-plugin is installed like this:

easy_install transmissionrpc

Installation of Mailman in Ubuntu

 
Mailman is a powerful mailing list manager. It has a decent web interface for users and admins and offers content filtering, archiving, and much more. This documentation is based on Mailman v.2.1.14, Ubuntu 11.04, and Exim v.4.7.4 as MTA.

Package installation

To install the necessary packages this line is used:

aptitude install mailman exim4-daemon-heavy

Initial config

Unfortunately, the next steps are not part of the process of package installation but have to be done manually. First, a site password has to be set:

mmsitepass

Now, the initial list has to be created:

newlist mailman

Exim setup

To give Exim awareness of an existing Mailman setup, two ways are possible. The first one is based on the /etc/aliases file where new lists need to be added by hand. The second way is more comfortable, yet needs some customisation on the Exim part.

Alias file based

The previous step of creating the initial Mailman list results in the following output:

To finish creating your mailing list, you must edit your /etc/aliases (or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:

## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

So, the lines after “## mailman mailing list” are to be copied and pasted at the end of the file /etc/aliases. This has to be done each time a new list is created. The changes are activated by the following line:

newaliases
Exim config file based

The second way of configuration makes Mailman speak to Exim directly. Therefore, a couple of changes are to be made to different sections of the Exim config file at /etc/exim4/exim4.config.template.

In the section “MAIN CONFIGURATION SETTINGS” these lines are to be added:

# ---------- MAILMAN --------------------------------------------------------
# Home dir for your Mailman installation -- aka Mailman's prefix
# directory.
MAILMAN_HOME=/var/lib/mailman
MAILMAN_WRAP=MAILMAN_HOME/mail/mailman

# User and group for Mailman, should match your --with-mail-gid
# switch to Mailman's configure script.
MAILMAN_USER=list
MAILMAN_GROUP=daemon
# ---------- /MAILMAN -------------------------------------------------------

In “ROUTERS CONFIGURATION” just below “begin routers” these line are new:

# ---------- MAILMAN --------------------------------------------------------
# Messages get sent out with envelope from "mailman-bounces@virtual_domain"
# But mailman doesn't put such addresses in the aliases. Recognise these here.
mailman_workaround:
  domains = +local_domains
  require_files = MAILMAN_HOME/lists/$local_part/config.pck
  driver = accept
  local_parts = mailman
  local_part_suffix_optional
  local_part_suffix = -bounces : -bounces+* : \
           -confirm+* : -join : -leave : \
           -subscribe : -unsubscribe : \
           -owner : -request : -admin
  transport = mailman_transport
  group = MAILMAN_GROUP

# Mailman lists
mailman_router:
  domains = +local_domains
  require_files = MAILMAN_HOME/lists/$local_part/config.pck
  driver = accept
  local_part_suffix_optional
  local_part_suffix = -bounces : -bounces+* : \
                      -confirm+* : -join : -leave : \
                      -subscribe : -unsubscribe : \
                      -owner : -request : -admin
  transport = mailman_transport
  group = MAILMAN_GROUP
# ---------- /MAILMAN -------------------------------------------------------

In section “TRANSPORTS CONFIGURATION” just after “begin transports” the next line need to be added:

# ---------- MAILMAN --------------------------------------------------------
mailman_transport:
  driver = pipe
  command = MAILMAN_WRAP \
            '${if def:local_part_suffix \
                  {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                  {post}}' \
            $local_part
  current_directory = MAILMAN_HOME
  home_directory = MAILMAN_HOME
  user = MAILMAN_USER
  group = MAILMAN_GROUP
  freeze_exec_fail = true
# ---------- /MAILMAN -------------------------------------------------------

The new config is processed and set up by this line:

update-exim4.conf && service exim4 restart

Apache config

Mailman comes with a nice web UI and even a fitting config file for Apache. In /etc/apache2/sites-available/default the next two line are to be inserted right before the end of the file:

Include /etc/mailman/apache.conf
RedirectMatch ^/mailman(\/*)$ http://hostname.yourdomain.tld/cgi-bin/mailman/listinfo

The first line lets Apache parse the Mailman configuration file. The second line redirects all requests for http://hostname.yourdomain.tld/mailman to the listinfo page of Mailman at http://hostname.yourdomain.tld/cgi-bin/mailman/listinfo.

The changes are activated like this:

service apache2 restart

Workaround for list archives-bug in Ubuntu

In recent releases of the Mailman package for Ubuntu, the privileges on the directories of list-archives are not set properly so that new posts are not archived at all. To fix this the following line will help:

chown -R list /var/lib/mailman/archives/private/

In case there are already posts which are not indexed, the archive can be reinitialized like this:

/var/lib/mailman/bin/unshunt

Testing webserver-security with Nikto

A decent tool to test a webserver’s security setup is Nikto. It performs comprehensive tests on any given webserver and outputs its vulnerabilities. Using Ubuntu, the tool is easily available. It can be installed like this:

aptitude install nikto

To perform an actual test, the basic syntax looks like this:

nikto -h www.serverofinterest.tld

Depending on the extend of the test and the vulnerability of the server in question, the output might take a while. Yet, it will be quite enlightening as to where a server’s problem are.