# uname -a - Mot-clé - server

The war on SPAM: an review of the real world tools

Mathieu — Tue, 12 Sep 2017 02:54:00 +0200

Anti-spam techniques review: a few hints and tools review from my own experience.

Spam mesage are very common these days, but filtering them out is not as easy as it seems. The filtering techniques have evolved at the same rate than the spammers' evasive techniques, and the risk of filtering out a legitimate message is greater than ever.

It is also quite difficult to find good and up-to-date counter-measures list that anyone can implement.

Here is a summary of the anti-spam strategies I used / am still using. I hope it will help you understanding today's threats, and build your own solutions.

Definitions

MTA : Mail Transport Agent : this is the software that will actually do mail delivery. It is listening on port 25 and answers to SMTP commands. Some common MTAs : Postfix, Exim. More about MTA.
MX : MX records are DNS entries that are identifying the server responsible for mail delivery for the domain. More about MX records.
RBL : Realtime Blackhole List : a list of blacklisted IPs, that should be considered as spam sources. It is called Realtime because they are constantly updated. More about RBL.
RFC : Request For Comments, these are proposal for norms, some of them become norms. More about RFC.
IPS : Intrusion Protection System : these are "smart firewalls" that are blocking malicious requests, often based on behavioral rules. More about IPS.

The goals

My personal goals on SPAM war are pretty short:

Minimum false positive: having a spam is better than missing an important mail, try keeping the "permanent bashing" as low as possible
Hit harder on reoffending: coming-back spammers should be slapped harder
Internet neutrality: try not to encourage big mail farm, and let fair little providers doing their business

Available techniques

Blacklist / Blackhole Lists

Blacklists, Blackhole Lists (or RBLs) are the most ancient and most common measures for reducing spam. They are still pretty accurate, but:

It depends A LOT on the quality of the list, trashy lists are very common and they would end up sucking resources for no result, or worse, blocking legitimate emails
They are only accurate when updated often. I mean, very often (the R in RBL).
You should not use it directly on the MTA, these lists are an aggressive artefact of the past, where spam did not come from mail farms.
Very few are implementing IPv6, I agree that IPv6 spam is quite anecdotal, but it will probably change pretty soon (believe me)

Greylist

Greylisting is issuing a temporary REJECT code to force the foreign server to keep the message and send it back later. It aims at increasing the "cost per mail" for spam farms, as they cannot "hit and run" as fast as before.

The main culprits are that some providers are not implementing it well (hello Facebook) and so it needs an educated whitelist to work properly.

Some spammers are also re-sending the same mail several times in case of failure, looking like a legitimate mail server, and making Greylisting inefficient.

It is also hurting the fastness of the mail transmission, as the retry may occur several tens minutes after, slowing the mail delivery with little control on delays.

Also, some legitimate mail farms (hello OVH) are distributing their retry on several servers, making Greylisting inapplicable without fully whitelisting them.

RFC compliance

Spammers are often running special softwares for their crafted emails, tightening RFC compliance may be a good way to kick them out.

It can be as simple as forcing an HELO on SMTP protocol, or more tricky like checking the mail headers or enforcing a valid reverse.

In the majority of cases, it is very efficient, but:

Some home-made servers, especially Synology or Windows servers may be blocked while they are sending legitimate email. These servers are often ran by people who doesn't know or care on how to correctly setup a mail server. These buggy setups are more common than you think, and they are often legitimate senders, who have no clue of what is wrong, and are not willing to fix it (did I mentioned banking companies?).
In the vast majority of cases, IPv6-ready servers have no reverse on their IPv6 addresses and/or the IPv6 reverse is wrong.

SPF and DKIM

SPF and DKIM are anti-spoofing techniques. They does not guarantee that a mail is legitimate, but if the controls are showing an anomaly, it is very likely to be spam (or worse : scam or social engineering tentative).

The SPF technique is based on IP or sending domain whitelist: the sending email domain publishes a list of servers allowed to send email, along with a hint on what is expected if it does not pass (soft or hard reject).
DKIM is much more complex as the sending mail server has to cryptographically sign every message with a domain-specific key, which is then published in a special domain record.

SPF has been proven efficient at its beginnings, but today many spammers are just using stolen email accounts or custom domains that does not publish any SPF records, making it less pertinent.

DKIM is, like SPF, an anti spoofing technique, and spammers may be likely to sign mails from their custom domain if it becomes a necessity. Like SPF, a signed mail is not necessarily a clean mail. By the way, signature problems are pretty comon, and trashing an offending DKIM may not be the right behavior: Yahoo broke a lot of mailing lists when they enforced their DMARC policy.

To conclude, DKIM is relevant if you need to certify outgoing mails or if you are enforcing policies inside your company (to block spoofed email targeting your organisation) but it is definitely not an efficient anti-spam measure. And the recipient's servers may decide to simply ignore your painfully-configured DKIM headers.

Bayesian filters

Bayesian filters are frequency-based spam detection mechanisms. The idea is to sort out ham and spam for a short period of time, to let it "learn" what spam is made of, for efficient content-based detection. It has the benefit of being organisation-specific, as what is ham and what is spam may vary from one company to another (a company selling drugs may not be willing to filter out every message containing the word "pill").

But the learning process has to be taken seriously, and many end-users are just deleting spam instead of marking it for feeding the learning. By the way, the learning process needs IMAP folders to sort mails, and it will not work properly if all users are using POP mailboxes.

Spammers techniques

Or "the today's weapons of this war" .

Here is a short review of the spammers techniques I know, and some counter measures.

Address guessing

Some spammers are taking random web domains from their crawling, and then try to send their mails to commonly used addresses patterns. It can be webmaster@ ; ceo@ or whatever. These are easy to spot in log files, and a well configured MTA can take counter measures to lock out these guesses. Free (French ISP) is actually implementing this: postmaster.free.fr/index_en.html

Unfortunately, some legitimate email are sometimes sent to non existent addresses (typo, user deleted, etc) and legitimate MTA sometimes get blocked if the ban trigger is too low.

Moreover, nowadays' spammers are distributing their guesses trough zombie machines to stay under triggers, making it hard to spot.

Botnets

A lot of spammers are using zombies machines to send a high amount of mail in a short amount of time. Commercial ISP are taking the problem seriously, and many are blocking or filtering port 25 on their dynamic ranges, making impossible to have a custom mail server at home, but also preventing infected machines from sending direct-to-SMTP queries.

Direct to SMTP connections, ignoring MXes

Some spammers are just scanning IP ranges and directly talking to MTA, even if these MTAs are internal and pointed by no MX records. You may think that an authoritarian firewall is the neat solution, but it may be worth collecting these feisty IPs and feed them to an IPS, to protect the network from their guesses on the real MTAs.

Fake bounces and backsquatting

Sometimes you get an Undelivered Message notice (DSN) for a mail you never sent. This is probably backsquatting.
Backsquatting is sending email to a buggy address with a valid "from" address. An incorrectly configured mailserver would reply straight away to the from address to notify the failed delivery, instead of rejecting the mail and letting the foreign server doing the dirty job.

These configuration errors are pretty common, sometimes in defaut configurations or example configurations, but they can be easily avoided (look for documentation about backsquatting for your MTA, and test if your y server is vulnerable).

Real life advices

I am sorry, I don't have the magic wand to stop all Spam. A good spam fighting solution is always a combination of techniques, SpamAssassin for instance uses scoring from RBL as well as a bayesian filter and SPF checks.

I think that constant monitoring is important. Not just automated monitoring, but also clever log reading and mind openness on what can be a better solution for each problem. You never know what can happen in a spammer mind, and what works today may not work tomorrow. The Internet of Things is already a game changer.

I also advise you to be careful. Some decisions on our implementations may really hurt the Internet. Locking whole countries out is not without consequences, and the rise of IPv6 Internet has to be take into consideration from now.

Things are often not that pretty in mail servers, the temptation is great for a default blocking policy (hello MailInBlack). But as sysadmins, it is our responsability to not abuse and not hurting the smallest actors in the market (mails not coming from big farms). That may be a big word, but in my opinion, the freedom of the Internet also count on our neutrality on mail processing.

Thanks for reading.

Debian 8 : Limit SSH users to SFTP

Mathieu — Thu, 18 Feb 2016 10:38:00 +0100

Let’s say you want to configure a secure remote file access for you users, but you can’t use FTPS for some reasons (problems with passive mode and commercial firewalls ? Yes !). Your only secure solution is either a VPN, or a SFTP access.

SFTP is great, but it may implies giving full command line access to your end users. In order to prevent that, you could set-up a jailed SSH access with Jailkit and some bind mount, but it’s not that trivial to configure and to maintain ; and it may not work with software virtualization (Docker, LXCs…). There is a simpler solution.

The solution is : use the native chroot and limitations abilities of OpenSSH. Here is how.

Warning!

You should not configure this on your primary SSH access. By doing so, you will simply lock you out of your server.

In this article, we will set up a completely new instance of OpennSSH server, running next to the original, and handling SFTP only.

1. Setup the secondary SSH access (SFTP-only)

Create a new configuration file by copying the primary configuration :

cp /etc/ssh/sshd_config /etc/ssh/sftp_config

Now edit the file /etc/ssh/sftp_config and change the listening port (for instance 10022) :

Port 10022

Change the PID file for this new instance, set something meaningful :

PidFile /var/run/sftp.pid

Then add these lines to /etc/ssh/sftp_config :

ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

Here is a sample of a full configuration :

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 10022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

PidFile /var/run/sftp.pid

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Now, let’s configure autostart. Copy /lib/systemd/system/ssh.service to /lib/systemd/system/sftp.service and adjust settings :

[Unit]
Description=OpenBSD Secure Shell server (SFTP only)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS -f /etc/ssh/sftp.conf
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sftp.service

And enable your service :

systemctl enable sftp.service

Make sure the symlink /etc/systemd/system/sftp.service is created.

And try to start it :

service sftp start

2. Reconfigure the primary SSH access

In order to prevent normal users to log into a full shell, we have to change the primary configuration.

The configuration file should be located in /etc/ssh/sshd_config . Add an AllowUsers or AllowGroups directive to this file :

# One or the other but not both!
AllowUsers root admin
#AllowGroups sudo

Here is a sample of a full configuration :

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
AllowUsers root admin

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

Restart your primary SSH access, but don’t close your terminal afterwards :

service ssh restart

Now open a new terminal and check that your primary SSH is still working. If not, rollback your configuration.

3. Conclusion

Now you should have two SSH sockets listening : one for everyone using exclusively SFTP, and the other with full SSH access for authorized accounts.

Don’t hesitate to reply in comments if you encounter problems.

Sources

https://wiki.archlinux.org/index.php/SFTP_chroot

Set-up SQL quarantine with Amavisd-new and ISPConfig

Mathieu — Sun, 06 Dec 2015 16:56:00 +0100

It's documented, but it took me two days to do it correctly, so here is how to reconfigure an ISPConfig installation of Amavis to store quarantined mail in SQL database, in order to install a quarantine viewer like Mailzu.

1. Prerequisites

A working Postfix+Amavis stack with ISPConfig
A working SQL (PostgreSQL, MySQL...) database
Optional : a working mail server with PHP (for Mailzu)

Jump to Installation if you know what you are doing.

2. Off-subject generic explanations

2.1 Amavis and ISPConfig policies

ISPConfig policies, Tag-Levels

In a default ISPConfig installation per-user ISPConfig policies are loaded. The configuration file for Amavis, written by ISPConfig contains :

@lookup_sql_dsn =
   ( ['DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306', 'ispconfig', 'xxxx'] );
$sql_select_policy =
   'SELECT *,spamfilter_users.id'.
   ' FROM spamfilter_users LEFT JOIN spamfilter_policy ON spamfilter_users.policy_id=spamfilter_policy.id'.
   ' WHERE spamfilter_users.email IN (%k) ORDER BY spamfilter_users.priority DESC';
$sql_select_white_black_list = 'SELECT wb FROM spamfilter_wblist'.
    ' WHERE (spamfilter_wblist.rid=?) AND (spamfilter_wblist.email IN (%k))' .
    ' ORDER BY spamfilter_wblist.priority DESC';

It means that whatever you would set as $sa_spam_subject_tag, $sa_tag_level_deflt, $sa_tag2_level_deflt, $sa_kill_level_deflt, $sa_dsn_cutoff_level, it will be overridden by per-user policies.

The ISPConfig policies can be changed in tab Email => Spamfilter => Policy in ISPConfig panel. If you struggle wondering why your message keeps getting smashed at level 4.5, look at the sa_tag_level in policies. We will have to change values in that policies, to make the SQL quarantine working.

2.2 Lookup DSN and Storage DSN

DSN (Data Source Name) are the connection strings with host, username, and password, used to connect to databases.

Amavis can set two DSN : one for Policies lookup (used to retrieve ISPConfig policies from Panel), and one for storage of mail meta informations and quarantine. We will use the Storage DSN to set up a secondary database for quarantine storage, to not mess with existing ISPConfig database.

2.3 Levels and cutoffs

Amavis uses Spamassassin to score the mail, in order to decide what to do with it. The category of test (spam test, antivirus, etc) and the score along with levels determines the actions Amavis will trigger, and the final destiny where the mail belongs.

Spamassassin levels are :

tag_level : a message above that score will be tagged with X-Spam-Status, X-Spam-Score and X-Spam-Level headers.
tag2_level : a message above that score will be marked as X-Spam-Status: Yes and the subject is changed if sa_spam_modifies_subj is set to true.
kill_level : a message above that score is taken to the final_spam_destiny, and quarantined, it will not be delivered unless D_PASS is set to final_spam_destiny.
dsn_cutoff_level : a message above that level will never trigger a bounce or a reject, whatever spam_destiny is.
quarantine_cutoff_level : a message above that level will not be quarantined.

2.4 Final destinations

Once the message is categorized by Amavis tests (through SpamAssassin, ClamAV, etc), Amavis decides if it should be delivered to user mailbox or not, and if a bounce will be issued.

This is the purpose of $final_virus_destiny, $final_spam_destiny, $final_banned_destiny, $final_bad_header_destiny.

They can take the following values :

D_PASS : mail will be delivered to inbox.
D_BOUNCE : mail will not be delivered, and a delivery status notification will be returned by Postifx to sender (except if the score exceeds the dsn_cutoff level)
D_REJECT : Postfix will answer REJECT to the distant mail server, and the distant mail server may produce a delivery status notification to the user
D_DISCARD : forgive and forget : the mail will not be delivered and the sender is not informed. The mail may be quarantined if the quarantine_cutoff level is not exceeded.

3. Installation

For Amavis : Nothing ! Amavis comes out-of-the-box with SQL storage.
For Mailzu : see Mailzu section.

4. Configuration

4.1 Database

Create an user and a database for quarantine storage :

# mysql -u root -p
mysql> CREATE DATABASE amavis_storage;
mysql> CREATE USER 'amavis_storage'@'localhost' IDENTIFIED BY 'xxxx';
mysql> GRANT ALL PRIVILEGES ON amavis_storage.* TO 'amavis_storage'@'localhost';
mysql> FLUSH PRIVILEGES;

Load the initial schema from Amavis docs (usually located in /usr/share/doc/amavisd-new/ ).

Delete unnecessary tables, as we will be using this database only for mail storage and not for lookups :

# mysql -u amavis_storage -p amavis_storage
mysql> DROP TABLE users;
mysql> DROP TABLE mailaddr;
mysql> DROP TABLE policy;
mysql> DROP TABLE wblist;

Nota Bene : while executing DROP TABLE users, don't be silly, and do not remove mysql users database.

4.2 Amavis

Update your Amavis configuration /etc/amavis/conf.d/50_user :

@storage_sql_dsn = ( ['DBI:mysql:database=amavis_storage;host=127.0.0.1;port=3306', 'amavis_storage', 'xxxx'] );  # none, same, or separate database

# Quarantine SPAM into SQL server.
$spam_quarantine_to = 'spam-quarantine';
$spam_quarantine_method = 'sql:';

# Quarantine VIRUS into SQL server.
$virus_quarantine_to = 'virus-quarantine';
$virus_quarantine_method = 'sql:';

# Quarantine BANNED message into SQL server.
$banned_quarantine_to = 'banned-quarantine';
$banned_files_quarantine_method = 'sql:';

# Quarantine Bad Header message into SQL server.
$bad_header_quarantine_method = 'sql:';
$bad_header_quarantine_to = 'badheader-quarantine';

# Do not store non-quarantined messages info
# You can set it to 1 (the default) to test if Amavis is filling correctly the tables maddr, msgs, and msgcrpt
$sql_store_info_for_all_msgs = 0;

#
# SQL Select statements
#

$sql_select_policy =
   'SELECT *,spamfilter_users.id'.
   ' FROM spamfilter_users LEFT JOIN spamfilter_policy ON spamfilter_users.policy_id=spamfilter_policy.id'.
   ' WHERE spamfilter_users.email IN (%k) ORDER BY spamfilter_users.priority DESC';

$sql_select_white_black_list = 'SELECT wb FROM spamfilter_wblist'.
    ' WHERE (spamfilter_wblist.rid=?) AND (spamfilter_wblist.email IN (%k))' .
    ' ORDER BY spamfilter_wblist.priority DESC';

#
# Quarantine settings
#

$final_virus_destiny = D_BOUNCE;
$final_spam_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_bad_header_destiny = D_PASS;

# Default settings, we st this very high to not filter aut emails accidently
$sa_spam_subject_tag = '[SPAM] ';
$sa_tag_level_deflt  = 20.0;  # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 60.0; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 60.0; # triggers spam evasive actions
$sa_dsn_cutoff_level = 100;   # spam level beyond which a DSN is not sent
#$sa_debug = 1;

#
# Disable spam and virus notifications for the admin user.
# Can be overridden by the policies in mysql
#

$virus_admin = undef;
$spam_admin = undef;

#
# Enable Logging
#

$DO_SYSLOG = 1;
$LOGFILE = "/var/log/amavis.log";  # (defaults to empty, no log)

# Set the log_level to 5 for debugging
$log_level = 0;                # (defaults to 0)

4.3 ISPConfig policies

Remember that ISPconfig policies are overriding a lot of our configuration in 50_user. In order to majke the quarantine work, you have to reconfigure all the available policies in ISPConfig Panel.

Look at your policies list, you have to change the quarantine settings for every policies :

ISPConfig Mail Spamfilter Policy

When editing a policy, on the Quarantine tab, set the destinations :

ISPConfig Mail Spamfilter Policy Quarantine destinations

If you do not fill something in these fields, Amavis will not store quarantined mails in SQL database, and will just discard it !

These fields correspond to the virus_quarantine_to, spam_quarantine_to, banned_quarantine_to, bad_header_quarantine_to variables in Amavis configuration, and an empty value is overriding those we set in Amavis configuration.

4.4 Test

Send some spam to your server, check if the tables are populated :

mysql> SELECT * FROM maddr;

Check if meta informations are populated :

mysql> SELECT * FROM msgs;
mysql> SELECT * FROM msgrcpt;

And if quarantine is filling :

mysql> SELECT * FROM quarantine;

5. Cleanup !

You should not "setup and forget" your quarantine SQL storage. Messages has to be deleted periodically, otherwise your database will grow forever. Look at the documentaion in /usr/share/docs/amavisd-new to make a cronjob like this :

#!/bin/bash

SQL_HOST="localhost";
SQL_LOGIN="amavis_storage"
SQL_PASSWORD="xxxx"
SQL_DB="amavis_storage"

mysql --user="$SQL_LOGIN" --password="$SQL_PASSWORD" --host="$SQL_HOST" $SQL_DB -e " \
  DELETE FROM msgs WHERE time_num < UNIX_TIMESTAMP() - 30*24*3600; \
  DELETE FROM msgrcpt WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE mail_id=msgrcpt.mail_id); \
  DELETE FROM quarantine WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE mail_id=quarantine.mail_id); \
  DELETE FROM maddr WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE sid=id) AND NOT EXISTS (SELECT 1 FROM msgrcpt WHERE rid=id); \
"

6. Mailzu

I have to admit, Mailzu seems a bit obsolete as I had to patch to make it working with Amavis 3.3 tables. But it still works pretty well for a simple task like reading and releasing quarantine mails.

6.1 Installation

Download the source files at http://sourceforge.net/projects/mailzu/.

62. Patch

The existing Mailzu source code is quite old, and the schema of Amavis SQL tables changed. Download and apply this patch in to make Mailzu work.

6.3 Configuration

I suppose that you know how to spawn PHP with CGI to serve the Mailzu files.

Configure your database login and password in config/config.php :

$conf['db']['dbType'] = 'mysql';
$conf['db']['dbUser'] = 'amavis_storage';
$conf['db']['dbPass'] = 'xxxx';
$conf['db']['dbName'] = 'amavis_storage';
$conf['db']['hostSpec'] = 'localhost:3306';

I am using IMAP login to authenticate in Mailzu. Unfortunately, I had to turn off SSL authentication, as it wasn't working. Here is my configuration :

$conf['auth']['serverType'] = 'imap';
$conf['auth']['imap_hosts'] = array( 'localhost:143' );
$conf['auth']['imap_type'] = 'imaptls';
$conf['auth']['imap_domain_name'] = 'example.com';

Don't forget to set yourself "super" :

$conf['auth']['s_admins'] = array ('me@example.com');

And to set your web uri :

$conf['app']['weburi'] = 'https://example.com/mailzu';

6.4 Configure in-app release

Mailzu can also release quarantined mail. I did not implement this function, but you have to set up the amavisd-release internface on an inet socket on port 9998, instead of the existing unix socket located at /var/lib/amavis/amavisd.sock . Read more.

References

Configurer dibbler-client pour IPv6 sur une Dedibox (Online.net) avec Debian 8 (Jessie)

Mathieu — Wed, 21 Oct 2015 14:24:00 +0200

La documentation d’Online pour IPv6 ne traite pas le cas de Debian, Ubuntu, ou toute distribution utilisant systemd (CentOS6, etc). La documention doit être étendue pour ajouter le service sysetmd au démarrage, en lieu et place de l’init script.

Vérifiez que l’IPv6 est activé

Cela devrait normalement être le cas, puisque le noyau par défaut de Debian 8 inclut nativement IPv6 et ne peut pas être désactivé. Mais au cas où vous ne verriez pas le link-local sur vos interfaces :

Changer dans /etc/modprobe.d/local.conf :

options ipv6 disable=0

Ajouter dans /etc/modules :

ipv6

Il faudra sans doute redémarrer pour appliquer les changments.

Récupérez votre préfixe et votre DUID depuis la console d’Online

Vous devez demander l’activation de IPv6 au support et créer votre /64 dans la console d’Online pour obtenir votre DUID.

Créez un /64 et n’utilisez pas le /48 ou le 56 directement, vous pourriez le regretter si vous souhaitez redécouper le réseau. Vous n’avez qu’un seul /48 par compte, un /56 pour chaque serveur, et un /64 pour chaque failover souscrit.

Configurez l’interface réseau

Encore une fois, c’est sans doute facultatif puisque Dibbler reconfigure l’interface lorsqu’il se lance, donc explicitons ça dans le fichier /etc/network/interfaces, juste au cas où :

iface eth0 inet6 static
    address your_ipv6_address
    netmask 64
    accept_ra 2

Notes sur Proxmox et le forwarding

Sous Proxmox on travaille sur l’interface bridge, c’est vmbr0 et non pas eth0.

Si le forwarding est activé, vous devez forcer le accept_ra à 2, une valeur de 1 fera ignorer les router advertisements lorsque le forwarding est activé. Explications. Ajoutez dans sysctl.conf :

net.ipv6.conf.vmbr0.accept_ra = 2

Notez bien que dans le cas où vous adressez vos machines virtuelles en IPv6 vous ne devez pas brancher l’interface IPv6 de vos VM directement sur l’interface vmbr0. Voilà pourquoi.

Compilez et installez Dibbler

Téléchargez Dibbler 1.0.1 à partir du site officiel
Installez build-essential : apt-get install build-essential
Décompressez Dibbler : tar -xzf dibbler-1.0.1.tar.gz && cd dibbler-1.0.1
Compilez et installez Dibbler : ./configure && ./make

Configurez Dibbler

Créez les dossiers et fichiers de configuration comme le précise la documentation :

Configurez le DUID dans /var/lib/dibbler/client-duid :

mkdir /var/lib/dibbler/
touch /var/lib/dibbler/client-duid
chmod 640 /var/lib/client-duid
# Set up you duid in client-duid
vim /var/lib/client-duid

Configurez /etc/dibbler/client.conf :

mkdir /etc/dibbler
vim /etc/dibbler/client.conf

Voici le contenu de mon client.conf :

auth-protocol reconfigure-key
auth-replay monotonic
auth-methods digest-hmac-md5
duid-type duid-ll
inactive-mode
log-level 8
iface eth0 {
    pd
    ia
}

Encore une fois, c’est à adapter en fonction du nom de votre interface.

Démarrez le client pour tester la connectivité :

dibbler-client run

Pour vérifier que Dibbler a configuré l’interface, pressez CTRL+Z pour suspendre le processus et vérifiez que l’IP et les routes sont bien configurées. Tapez la commande “fg” pour retourner au processus en cours d’exécution, et tapez CTRL+C pour stopper Dibbler.

Si pendant l’opération les routes et les IPs sont incorrectes, vérifiez que votre pare feu accepte les connexions entrantes par le port 546 UDP.

Configurez Dibbler au démarrage

Cette section est différente de la documentation d’Online.

Avant systemd, le système d’init par dépendances se contentait d’un script dans /etc/init.d/. Avec systemd, il faut créer un fichier service dans /etc/systemd/system/ .

Créez le fichier suivant : /etc/systemd/system/dibbler.service :

[Unit]
Description=Dibbler
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/dibbler-client start
ExecStop=/usr/local/sbin/dibbler-client stop
PrivateTmp=true
NonBlocking=yes

[Install]
WantedBy=multi-user.target

Lancez la commande suivante pour que systemd lise le fichier :

systemctl daemon-reload

Et activez le service :

systemctl enable dibbler.service

Et essayez de le lancer pour la première fois :

systemctl start dibbler.service

Vérifions que tout est correct :

service dibbler status
ifconfig
route -6
ping6 whatever-you-want.com

Si tout va bien, redémarrez et l’IPv6 fonctionnera dès le démarrage !

Addendum : juste au cas où, n’utilisez pas resolvconf pour pousser les DNS IPv6 automatiquement, conservez autant que possible vos DNS IPv4. Ça serait tellement dommage que votre connectivité IPv6 saute et que vous vous retrouviez sans DNS (oui ça m’est arrivé…).

Sources

Configure dibbler-client for IPV6 networking on Dedibox (or any Online.net) servers with Debian 8 (Jessie)

Mathieu — Wed, 21 Oct 2015 12:50:00 +0200

The Online documentation for IPv6 is not dealing with the case of Debian 8, Ubuntu, or any distribution using systemd. Systemd replaces upstart, so the procedure has to be extended to add systemd service for startup, replacing the previoux behavior that was using init scripts.

Ensure that you are IPv6-proof

It should be the case as Debian 8 is shipping a kernel with native IPv6, but just to be sure :

In /etc/modprobe.d/local.conf :

options ipv6 disable=0

In /etc/modules :

ipv6

You may have to reboot in order to apply the changes.

Set up your IPv6 prefix and get your DUID on Online console

You have to request IPv6 activation to support and create your /64 on Online console before getting your DUID working.

Make a /64 and do not use your /48 or your /56 directly, as you may regret it. You can have only one /48 by account, one /56 by server, and one /64 by IP failover (the /48 is divided to make the /56 and so on).

Configure your network interface

It may not be mandatory as Dibbler will reconfigure your interface, but you have to ensure that you accept router advertisements. Add to /etc/network/interfaces :

iface eth0 inet6 static
    address your_ipv6_address
    netmask 64
    accept_ra 2

Notes about Proxmox and forwarding

On Proxmox, you are working on the bridge interface, it should be vmbr0 instead of eth0.

If you enabled forwarding on this interface (to give your VM an access to IPv6 network), you have to force the accept_ra to 2, while the default value of 1 wil make your Debian to ignore router advertisements when forwarding is enabled ! Read more. Add to sysctl.conf :

net.ipv6.conf.vmbr0.accept_ra = 2

Also do not set the IPv6 interface of your VM to vmbr0, as you can break your network access. Read more.

Compile and install Dibbler

Download Dibbler 1.0.1 from the offical website.
Install build-essential : apt-get install build-essential
Extract Dibbler : tar -xzf dibbler-1.0.1.tar.gz && cd dibbler-1.0.1
Compile and install Dibbler : ./configure && ./make

Configure Dibbler

Make the directories and set up according to the documentation :

Set up duid :

mkdir /var/lib/dibbler/
touch /var/lib/dibbler/client-duid
chmod 640 /var/lib/client-duid
# Set up you duid in client-duid
vim /var/lib/client-duid

Set up client.conf :

mkdir /etc/dibbler
vim /etc/dibbler/client.conf

The content of my client.conf :

auth-protocol reconfigure-key
auth-replay monotonic
auth-methods digest-hmac-md5
duid-type duid-ll
inactive-mode
log-level 8
iface eth0 {
    pd
    ia
}

Note that if your interface name is different you have to change it accordingly. For instance, on a Proxmox host server, it should be vmbr0 instead of eth0.

Start dibbler to try the connectivity :

dibbler-client run

Hit CTRL+Z to suspend the process and check that the IP and routes are configured. Type the command “fg” to get back to the running process and hit CTRL+C to stop it.

If it doesn’t work, check your firewall, dibbler needs to listen port 546 UDP.

Set Dibbler at startup

This section differs from Online documentation.

Before systemd, the dependency-based boot sequence only needed an init script, for instance /etc/init.d/dibbler . With systemd, you have to make a service file in /etc/systemd/system/ .

Make the following file : /etc/systemd/system/dibbler.service :

[Unit]
Description=Dibbler
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/dibbler-client start
ExecStop=/usr/local/sbin/dibbler-client stop
PrivateTmp=true
NonBlocking=yes

[Install]
WantedBy=multi-user.target

Run the following command to make systemd read file :

systemctl daemon-reload

Enable the service :

systemctl enable dibbler.service

And then, try to start it :

systemctl start dibbler.service

Check everything is fine :

service dibbler status
ifconfig
route -6
ping6 whatever-you-want.com

Reboot and the IPv6 networking should work at startup !

Addendum : just in case, don’t use resolvconf with IPv6 DNS pushing and if possible keep IPv4 DNS, it would be such a pity if the IPv6 networking crashes while your DNS servers are set to IPv6 addresses (yeah, it happened to to me)…

Sources

Postfix : configure postmaster, hostmaster, and abuse catchall for RFC compliance

Mathieu — Sat, 29 Aug 2015 18:02:00 +0200

This short howto will show you how to set up a catchall for common required email addresses. Some mail servers are testing if mail is accepted on this addresses to detect spammymail servers. Hostmaster address can also be used for domain Trading, to check the ownership of the domain.

1. Create a file named /etc/postfix/regexp-catchall.cf with the following content:

# Catchall to comply with RFC standards
/^postmaster@/    youshouldreadit@mydomain.com
/^hostmaster@/    youshouldreadit@mydomain.com
/^abuse@/         youshouldreadit@mydomain.com

Replace youshouldreadit@mydomain.com with a mail address you actually read.

2. Open /etc/postfix/main.cf and locate (or create) the line virtual_alias_maps, and add at the end regexp:/etc/postfix/regexp-catchall.cf, for instance:

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, regexp:/etc/postfix/regexp-catchall.cf

3. Restart Postfix.

Warning : read comment #4 for issues with this setup.

Nagios : quick and dirty patch to enable (force) SSL on check_mysql_health

Mathieu — Sat, 06 Jun 2015 16:10:00 +0200

Sometimes you don’t want to set up a VPN just to safely monitor your MySQL servers. Because SSL should be implemented in check_mysql_health, here is a quick and dirty patch for SSL connexion. I assume you already configured your MySQL server to use SSL if client wants to (or if user requires ssl).

File /usr/lib/nagios/plugins/check_mysql_health at line 1863, after the following block :

    } else {
      $self->{dsn} .= sprintf ";host=%s", $self->{hostname};
      $self->{dsn} .= sprintf ";port=%s", $self->{port}
          unless $self->{socket} || $self->{hostname} eq 'localhost';
      $self->{dsn} .= sprintf ";mysql_socket=%s", $self->{socket}
          if $self->{socket};

Add these lines :

    $self->{dsn} .= ";mysql_ssl=1";
    $self->{dsn} .= ";mysql_ssl_client_key=/etc/ssl/mysql/client.key";
    $self->{dsn} .= ";mysql_ssl_client_cert=/etc/ssl/mysql/client.crt";
    $self->{dsn} .= ";mysql_ssl_ca_file=/etc/ssl/mysql/ca.crt";

Where /etc/ssl/mysql/client.key is the path to client key, /etc/ssl/mysql/client.crt the path to client certificate, and /etc/ssl/mysql/ca.crt the path to the CA certificate.

It should work, while there is still no “SSL switch” on that plugin.

EDIT : actually there is an undocumented param named “—mycnf” which should allow you to enable SSL for client connection in a prettier way.

Configure sender rate limits to prevent spam, using cluebringer (policyd) with Postfix

Mathieu — Fri, 13 Mar 2015 09:18:00 +0100

This small how-to will show you how to configure cluebringer (aka policyd) to set a per-hour/per-user limit for sent mails. Note that sending to multiple recipient will count like multiple mails were sent.

This how-to is Debian-oriented but should apply to any unix operating system.

Requirements

A mail server with Postfix installed.

Installation

Install a DBMS (MySQL for instance), cluebringer, and cluebringer-webui :

apt-get install mysql-server cluebringer cluebringer-mysql cluebringer-webui

Note that cluebringer-webui will install apache as a dependency if you don’t already have a webserver.

Set-up the Cluebringer database

Get the initial database schema that correspond to your DBMS, for instance mysql :

cp /usr/share/doc/postfix-cluebringer/database/policyd-db.mysql.gz ~/ && gunzip ~/policyd-db.mysql.gz

Create the database, and populate it with the initial dump :

# cd  ~/ && mysql -u root -p
mysql> CREATE DATABASE cluebringer;
mysql> CREATE USER 'cluebringer'@'localhost' IDENTIFIED BY 'mypassword';
mysql> GRANT ALL PRIVILEGES ON cluebringer.* TO 'cluebringer'@'localhost';
mysql> \. policyd-db.mysql
mysql> quit
mysql> Bye

Note that on Debian I had to modify the dump to make it work, TYPE=InnoDB was rejected by MySQL as an invalid syntax.

Configure Cluebringer

Add your DBMS credentials to the file /etc/cluebringer/cluebringer.conf :

DSN=DBI:mysql:dbname=cluebringer;host=localhost

DB_Type=mysql
DB_Host=localhost
DB_Port=3306
DB_Name=cluebringer
Username=cluebringer
Password=mypassword

And start it :

service postfix-cluebringer start

Configure Cluebringer webui

Configure the file /etc/cluebringer/cluebringer-webui.conf with your DBMS credentials :

<?php

$DB_DSN="mysql:host=localhost;dbname=cluebringer";
$DB_USER="cluebringer";
$DB_PASS="mypassword";

Cluebringer Webui needs a web server to run. Copy the sample configuration from the package documentation :

cp /usr/share/doc/postfix-cluebringer-webui/examples/httpd/cluebringer-httpd.conf /etc/apache2/conf.d/

Restart Apache :

service apache2 restart

You may need to adjust a few things to access it from the outside. If you a really lazy, just make a ssh tunnel to access the webserver from localhost :

ssh -L 8008:localhost:80 mylogin@mymailserver

Don’t forget : you have to make this tunnel from the outside, do not run this command on server, it won’t work.

You should now be able to open http://localhost:8080/ and see your fresh new Cluebinger Webui !

Configure Cluebringer using its webui

Add a policy

Under Policies -> Main, disable Test policy (select policy and choose Action -> Change and switch Disabled to yes, validate)

Add a new policy : Action -> Add, give it a name and a description

Activate your new policy : select policy and choose Action -> Change (switch Disabled to no)

Add a new member to your policy : select it and choose Action -> Members, and then Action -> Add. Specify any as source and any as destination.

Go back to your policy, choose Action -> Members, and the select your member, do Action -> Change, and activate your new member (switch Disabled to no).

Add a quota

Under Quotas -> Configure, disable Test quotas.

Add a new quota : Choose Action -> Add

Name : whatever you want
Track : user@domain
Period (seconds) : 3600
Link to policy : specify the policy you created here
Verdict : Defer
Data : set a custom error message here
Comment : whatever you want

Activate your quota : switch Disabled to no.

Add a limit to your quota : select your quota, and choose Action -> Limits, then Action -> Add.

Type : MessageCount
Counter Limit : 200

Activate your limit : switch Disabled to no.

Configure Postfix to call Cluebringer for each mail sent

Open /etc/postfix/main.cf and locate the line smtpd_sender_restrictions.

Add check_policy_service inet:127.0.0.1:10031 at the end of the line, for instance :

smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, check_policy_service inet:127.0.0.1:10031

If the line does not exists, simply add it.

Don’t forget to restart Postfix :

service postfix restart

Check your config

You can now send some mails to see what happens. To check if these mails are passed to Cluebringer, connect to MySQL as the cluebringer user :

# mysql -u cluebringer -p cluebringer

And execute the query :

mysql> SELECT * FROM quotas_tracking;

You should see the value LastUpdate and Counter updating when sending a mail. Note that sending to multiple recipient will count like multiple mails were sent.

Pitfalls, bleeding edges, etc

Cluebringer versions prior to 2.1.x does not support IPv6, your customers won’t be able to send any mail if they have an IPv6 connection.

Unfortunately, the Debian stable version (wheezy) provides Cluebringer 2.0.10 within its repositories, as well as the experimental release of Debian (sid). As an alternative, you should consider installing the 2.1.x experimental Cluebringer from official website instead of Debian packages from repositories.

References

Set up an incremental backup with duplicity, rsync, and backupninja on Debian

Mathieu — Fri, 20 Feb 2015 22:08:00 +0100

Version française.

This is a not-so-concise how-to about setting up an incremental backup, using Backupninja with Duplicity backend on Debian.

Abstract

If you know what a backup is, you should know there are several types of backups :

A full backup is when you just copy all your files, hoping that the hard drive on the backup server will not explode after 3 backups.
An incremental backup consist in a base full backup, and the next backups are just "diffs" sent to the backup server, to keep track of modified files.

Obviously, a full backup is easier to read and to restore because it's just plain files, whereas an incremental backup has a specific file format to represent diffs. But considering the gain in speed, bandwidth, and disk space, your choice for a long-term backup solution should be the incremental backup.

The tools

Duplicity is an opensource software similar to rdiff-backup. It creates incremental backups. Duplicity can also encrypt your backups, so they can be safely sent to any remote disk provider. A classic setup for Duplicity would be using rsync as a backend to send files faster to the remote backup server, but you can also use a local drive, a remote FTP server, or an Amazon E3 cloud server. As the title says, I will be using rsync for that setup.

But what about databases ? Databases can't be saved by simply copying files, it could lead to corrupted and unusable data in your backups, so you would use a backup script to fetch your databases before sending it to Duplicity.

Good news : backupninja is the global solution you need. Backupninja is a sort of "backup-master" : it can fetch different type of data (files, databases...) from different sources and sent it to different destinations (plain backup, duplicity, etc). you just have to write a specific config file for each source !

We will use backupninja to fetch our databases, we will add these SQL archives to our files backup, send this to Duplicity backend, and finally send it to our backup server with rsync. And with just 3 config files (one by SQL type, one for Duplicity and rsync).

Let's go !

Requirements

A Debian machine to backup, let's call it production
A backup server, with SSH access (SSH is required for rsync, but an FTP server can do the job), let's call it backup

Configure the backup user on the remote machine

In order to send the backed up files to backup, we will need a way to authenticate from production without specifying a password.

First, be root on production : sudo -s

Then, create ssh key pairs : ssh-keygen -t rsa

The public key will set up on /root/.ssh/id_rsa.pub and the private key in /root/.ssh/id_rsa

Now, let's consider backup, check if your SSH server on backup acccepts the public key authentications. In /etc/ssh/sshd_config, you should have the lines :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

If not, simply add it (and restart ssh service).

Now, add the prod_server user on backup : useradd prod_server
You may want to change its home, I assume you know how to do it.

Now, back to production, simply copy the SSH public key to the backup file named /home/prod_server/.ssh/authorized_keys
The trashy way : scp /root/.ssh/id_rsa.pub root@backup:/home/prod_server/.ssh/authorized_keys
The classic way : copy/paste the content of production:/root/.ssh/id_rsa.pub at the end of the file backup:/home/prod_server/.ssh/authorized_keys

If you did it right, you should now be able to ssh from production to backup without password.

Install backupninja (and friends)

On production, use the Debian magic line : sudo apt-get install backupninja duplicity rsync

Configure databases dump

Okay, let's start configuring backupninja !

For MySQL, copy the sample file from /usr/share/doc/backupninja/examples/example.mysql to /etc/backup.d/10-alldb.mysql and change it for your own needs (the file is pretty trivial and well commented).

databases   = all
backupdir   = /var/backups/mysql
hotcopy     = no
sqldump     = yes
compress    = yes
configfile = /etc/mysql/debian.cnf

For PostgreSQL, all the same ! Copy /usr/share/doc/backupninja/examples/example.mysql to /etc/backup.d/10-alldb.pgsql and change the desired values.

backupdir = /var/backups/postgres
databases = all
compress = yes
format = plain

Why am I using that weird 10- at the beginning of the file ? For the same reason you have to prefix your files with number in Nginx configuration : for precedence. I need the database dumps to be done just before the files backup, otherwise, backupninja will send to duplicity the dumps of yesterday, and next create new dumps without including it in the Duplicity files for the current backup ! So, my database backup configuration files have to be like 10- and my Duplicity configuration file should be like 20-, for instance.

Note that the SQL dumps will be generated in /var/backups/ .

Configure Duplicity files backup

Again, copy the sample file : cp /usr/share/doc/backupninja/examples/example.dup /etc/backup.d/20-files.dup

And change its values :

# Disable testconnect because we use desturl
testconnect = no

# You may change this if you are a partition-maniac
tmpdir = /tmp

[gpg]
# Using symetric encryption for archive files
# Note that an encryption method is mandaory, either with symetric or private keys
# Don't forget to note that password somewhere !
password = whateveryouwant

[source]
# Specify the paths to your files
include = /var/spool/cron/crontabs
include = /var/log
include = /var/mail
include = /var/www
include = /etc
include = /root
include = /home
include = /usr/local

# And to your database dumps !
include = /var/backups/mysql
include = /var/backups/postgresql

# There are some files we don't need
# Don't forget to add the tmpdir in the exclude list, if it was included in the previous paths !
exclude = /home/*/.gnupg
exclude = /var/cache/backupninja/duplicity
exclude = /tmp

[dest]
# Adjust these to your own taste
incremental = yes
increments = 15
keep = 30
keepincroffulls = all

# Specify the backup server crendentials
## desturl = file:///usr/local/backup
## desturl = rsync://user@other.host//var/backup/bla
## desturl = s3+http://
## desturl = ftp://myftpuser@ftp.example.org/remote/ftp/path
desturl = rsync://prod_server@backup//home/prod_server/data

# Only if you choose FTP
# ftp_password = whateveryouwant

Note that this setup uses symetric encryption for duplicity archives, if you want an asymetric encryption to enforce the safety of your backups, you should read the docs and adapt this sample configuration.

Configure backupninja update frequency

You may have noticed that backupninja set up a cronjob in /etc/cron.d/backupninja but if you open that file, you will notice that this cronjob runs every hour. Why ? Because this cronjob is only used to start the backup manager, to check if a refresh is needed, not to actually run the backup every hour. You can set the backup frequency in the file /etc/backupninja.conf :

when = everyday at 01:00

Adjust it to your needs, and then save it. Note that you can combo multiple lines, if you want multiple start dates (read more).

Run you first backup, and check it

It's time for the first run ! If you don't want to wait for the cronjob, execute your first run with the command backupninja -d -n

If you see no errors, Bravo ! you have configured backupninja !

Now, let's check our backup : connect to backup and list files under /home/prod_server/data/

You should see the files created by duplicity, you cannot use it without some commands :

Show the collection status : duplicity collection-status file:///home/prod_server/data
List files in archive : duplicity list-current-files file:///home/prod_server/data
Restore the latest backup in a specific directory duplicity restore file:///home/prod_server/data/ /home/prod_server/test-restore/ (if you see errors but files are there after the command, it's because duplicity tries to chown files, while you were not root when starting the command).

Note that you must have Duplicity installed on backup on in order to use these commands on backup.

Also note that instead of using file:// on backup, you can run the command on production and use the ssh desturl.

Conclusion

You should now be able to implement a complete backup solution, using backupninja.

I hope this post was useful to you, you can write a comment below if you experienced problems with this how-to.

Configure Postfix as standalone single-domain SMTP server using Unix users and PAM on Debian

Mathieu — Sat, 01 Feb 2014 22:05:00 +0100

Here is a quick setup to configure Postfix mail server, using existing Unix users.

The server will process mails for only one domain, and every existing user on the server will have a mail box inside his home directory.

Abstract

Postfix is an SMTP server, it receives incoming mail from other SMTP servers, and allows client to send mails to other SMTP servers.

What we don't want is an open mail relay. A mail relay is a SMTP server that take anything from any client, and send it to any SMTP server. We only want trusted users to send emails, to prevent anonymous clients from sending spam.

Incoming mail will be processed either if :

The domain name of one of the recipient matches the mail server domain, and the mail user name is also a system user (SMTP servers can send us incoming mails).
The client who tries to sends the mail has successfully authenticated.

Postfix authentication for clients can be handled by SASL. SASL is a standard protocol to provide an authentication layer. It can query PAM, or other authentication providers (MySQL users, etc).

Notes :

We will use PAM for Unix users SMTP authentication.
Unix users are stored in /etc/passwd and their passwords are stored in /etc/shadow.
Mails will be stored in the ~/Maildir/ of each users, in Maildir format.

Postfix : installation and configuration

Install Postfix : apt-get install postfix

Answer the questions during installation to setup your mail domain (the "example.com" in user@example.com).

Modify config files :

/etc/postfix/main.cf :

Configure TLS and Maildir :

# TLS parameters smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = mail.example.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = example.com, localhost mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + home_mailbox = Maildir/ # These are the "no relay" restrictions smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces permit_sasl_authenticated reject_unauth_destination

/etc/postfix/master.cf :

Enable TLS and alternate (submission) ports :

submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING

SASL : installation and configuration

SASL plugin for Postfix (Cyrus) is part of the dependencies of Postfix server.

Install SASL administration tools : apt-get install sasl2-bin

Enable SASL daemon at startup : edit /etc/default/saslauthd and switch START to yes.

Start it manually for the first time : service saslauthd start

Enable PAM authentication for SASL

Check that PAM is part of the MECHANISMS variable in /etc/default/saslauthd :

MECHANISMS="pam"

Create /etc/pam.d/smtp :

# # /etc/pam.d/smtp - specify PAM SMTP behavior # @include common-auth @include common-account @include common-password @include common-session

Enable SASL for Postfix

Add to /etc/postfix/main.cf :

smtpd_sasl_auth_enable = yes

Create /etc/postfix/sasl/smtpd.conf :

pwcheck_method: saslauthd mech_list: PLAIN LOGIN

Adjust OPTIONS in /etc/default/saslauthd :

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Add postfix user to sasl group :

adduser postfix sasl

Configuration check

Restart all services (postfix, salsauthd).

Try authentication using SASL : testsaslauthd -u user -p password

Try authentication from command line, without mail client : https://qmail.jms1.net/test-auth.shtml

Try SMTP reception by sending mail to your domain (your MX fields in domain has to be configured accordingly).

Sources

Configure Munin graphs with Nginx, FastCGI, and Debian 7

Mathieu — Sun, 25 Aug 2013 11:40:00 +0200

Setting up Munin with Nginx can be a little harsh. Here is the ready-to-go solution for Debian Wheezy.

I will make the assumption that you have already configured Munin and Munin-node. I also assume that you didn’t change the CGI and CRON params in the Munin default configuration provided by the Debian package.

Abstract

In the default configuration, the HTML files for Munin graphes are generated by Cron, and are stored in /var/cache/munin/www/
To display Munin graphs, you have to call the munin-cgi-graph program located in /usr/lib/munin/cgi/
To display Munin extra HTML, you have to call the munin-cgi-html program located in /usr/lib/munin/cgi/
The configuration I use is an adapted version of Apache configuration delivered with the Debian package at /etc/munin/apache2.conf.
Unlike Apache, Nginx does not spawn CGI processes, you will have to make a startup script to create the appropriate sockets.
The spawned sockets run with the munin user, you will have to chown some logfiles and change logrotate configuration.

Installation

Let’s start with a basic Ningx installation : apt-get install nginx

Next, add fcgiwrap, the Ningx CGI wrapper : apt-get install fcgiwrap. Note that in the dependencies, you have spawn-fcgi. we will use it to create the CGI sockets.

The CGI sockets

To spawn the munin-cgi-graph and munin-cgi-html processes, create a startup script at /etc/init.d/munin-fastcgi :

#! /bin/sh ### BEGIN INIT INFO # Provides: munin-fastcgi # Required-Start: $remote_fs $network # Required-Stop: $remote_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: starts munin-fastcgi # Description: Spawn Munin FCGI sockets for Web access ### END INIT INFO # # munin-fastcgi Startup script for Munin CGI services # # chkconfig: - 84 15 # description: Loading Munin CGI services using spawn-cgi # HTML files and CGI. # # Author: Ryan Norbauer <ryan.norbauer@gmail.com> # Modified: Geoffrey Grosenbach http://topfunky.com # Modified: David Krmpotic http://davidhq.com # Modified: Kun Xi http://kunxi.org # Modified: http://drumcoder.co.uk/ # Modified: http://uname.pingveno.net/ DAEMON=/usr/bin/spawn-fcgi FCGI_GRAPH_SOCK=/var/run/munin/fastcgi-munin-graph.sock FCGI_HTML_SOCK=/var/run/munin/fastcgi-munin-html.sock WWW_USER=www-data FCGI_USER=munin FCGI_GROUP=munin FCGI_SPAWN_GRAPH=/usr/lib/munin/cgi/munin-cgi-graph FCGI_SPAWN_HTML=/usr/lib/munin/cgi/munin-cgi-html PIDFILE_GRAPH=/var/run/munin/fastcgi-munin-graph.pid PIDFILE_HTML=/var/run/munin/fastcgi-munin-html.pid DESC="Munin FCGI for Graph an HTML" # Gracefully exit if the package has been removed. test -x $DAEMON || exit 0 test -x $FCGI_SPAWN_GRAPH || exit 0 test -x $FCGI_SPAWN_HTML || exit 0 start() { $DAEMON -s $FCGI_GRAPH_SOCK -U $WWW_USER -u $FCGI_USER -g $FCGI_GROUP -P $PIDFILE_GRAPH $FCGI_SPAWN_GRAPH 2> /dev/null || echo "Graph Already running" $DAEMON -s $FCGI_HTML_SOCK -U $WWW_USER -u $FCGI_USER -g $FCGI_GROUP -P $PIDFILE_HTML $FCGI_SPAWN_HTML 2> /dev/null || echo "HTML Already running" } stop() { kill -QUIT `cat $PIDFILE_GRAPH` || echo "Graph not running" kill -QUIT `cat $PIDFILE_HTML` || echo "HTML Not running" } restart() { kill -HUP `cat $PIDFILE_GRAPH` || echo "Can't reload Graph" kill -HUP `cat $PIDFILE_HTML` || echo "Can't reload HTML" } case "$1" in start) echo "Starting $DESC: " start ;; stop) echo "Stopping $DESC: " stop ;; restart|reload) echo "Restarting $DESC: " stop # One second might not be time enough for a daemon to stop, # if this happens, d_start will fail (and dpkg will break if # the package is being upgraded). Change the timeout if needed # be, or change d_stop to have start-stop-daemon use --retry. # Notice that using --retry slows down the shutdown process somewhat. sleep 1 start ;; *) echo "Usage: $SCRIPTNAME {start|stop|restart|reload}" >&2 exit 3 ;; esac exit $?

Don’t forget to set it executable : chmod +x /etc/init.d/munin-fastcgi

Finally, add your startup script to runlevels : update-rc.d munin-fastcgi defaults

And start it : service munin-fastcgi start

Fix for log files

The log files are owned by www-data user. In our configuration, the CGI process is run by munin.

Change the owner of logfiles : chown munin /var/log/munin/munin-cgi-graph.log && chown munin /var/log/munin/munin-cgi-html.log

Change the logrotate configuration : open /etc/logrotate.d/munin and change create 640 www-data adm to create 640 munin adm for the two logfiles.

Nginx VirtualHost configuration

Create the following /etc/nginx/sites-available/munin :

server { #listen 80; ## listen for ipv4; this line is default and implied #listen [::]:80 default_server ipv6only=on; ## listen for ipv6 # Make site accessible from http://localhost/ server_name localhost; # Here, the whole vhost has auth requirements. # You can duplicate it to the graph and html locations if you have # something else that doesn't need auth. auth_basic "Private access"; auth_basic_user_file /etc/munin/munin_htpasswd; location /munin/ { alias /var/cache/munin/www/; # not authenticated => no rewrite (back to auth) if ($remote_user ~ ^$) { break; } # is on the right subtree ? set $ok "no"; # admin can see it all if ($remote_user = 'admin') { set $ok "yes"; } # only allow given path if ($uri ~ /munin/([^/]*)) { set $path $1; } if ($path = $remote_user) { set $ok "yes"; } # not allowed here ? redirect them where they should land if ($ok != "yes") { # redirect to where they should be rewrite / /munin/$remote_user/ redirect; } } location ^~ /munin-cgi/munin-cgi-graph/ { # not authenticated => no rewrite (back to auth) if ($remote_user ~ ^$) { break; } # is on the right subtree ? set $ok "no"; # admin can see it all if ($remote_user = 'admin') { set $ok "yes"; } # only allow given path if ($uri ~ /munin-cgi/munin-cgi-graph/([^/]*)) { set $path $1; } if ($path = $remote_user) { set $ok "yes"; } # not allowed here ? redirect them where they should land if ($ok != "yes") { # redirect to where they should be rewrite / /munin-cgi/munin-cgi-graph/$remote_user/ redirect; } fastcgi_split_path_info ^(/munin-cgi/munin-cgi-graph)(.*); fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass unix:/var/run/munin/fastcgi-munin-graph.sock; include fastcgi_params; } location ^~ /munin-cgi/munin-cgi-html/ { # not authenticated => no rewrite (back to auth) if ($remote_user ~ ^$) { break; } # is on the right subtree ? set $ok "no"; # admin can see it all if ($remote_user = 'admin') { set $ok "yes"; } # only allow given path if ($uri ~ /munin-cgi/munin-cgi-html/([^/]*)) { set $path $1; } if ($path = $remote_user) { set $ok "yes"; } # not allowed here ? redirect them where they should land if ($ok != "yes") { # redirect to where they should be rewrite / /munin-cgi/munin-cgi-html/$remote_user/ redirect; } fastcgi_split_path_info ^(/munin-cgi/munin-cgi-html)(.*); fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass unix:/var/run/munin/fastcgi-munin-html.sock; include fastcgi_params; } location /munin/static/ { alias /etc/munin/static/; } }

Don’t forget to enable your VirtualHost : ln -s /etc/nginx/sites-available/munin /etc/nginx/sites-enabled/munin

And to restart Nginx : service nginx restart

Htaccess creation

To protect our stats, the VirtualHost includes HTTP authentication. But you have to create the htpasswd file in /etc/munin/munin_htpasswd. To do so, you can install Apache Utils.

Install Apache utils : apt-get install apache2-utils

Create the htpasswd : touch /etc/munin/munin_htpasswd && chown root:www-data /etc/munin/munin_htpasswd && chmod 640 /etc/munin/munin_htpasswd

And add your admin password : htpasswd /etc/munin/munin_htpasswd

Conclusion

Your Munin installation will be available at http://localhost/munin/ with your admin password.

I hope I saved you from a headhache.

Sources

http://munin.readthedocs.org/en/latest/example/webserver/nginx.html

http://drumcoder.co.uk/blog/2010/aug/04/debian-initd-script-fcgi/

Configure 2-factor Yubikey authentication for Debian : the easiest way

Mathieu — Tue, 06 Aug 2013 00:20:00 +0200

One of last five years trending topics is the rise of Token authentication, to provide a safer way to authenticate than the classic login/password couple.

Today I will show you how to configure a 2-factor authentication (login/password + yubikey), in order to use it with your local Unix users as well as with SSH login (PAM powered).

In this tutorial, I will use the Yubico API, because it’s simpler. When using the API, the validity check will be computed by Yubico servers. By the way, you can set up your own authentication server if you don’t want to depend on Yubico servers.

First things first, you have to afford a Yubikey at http://www.yubico.com/
Get your Yubikey ID. You can use the 12 first digit of every Yubikey generated password, but you can also generate it from http://demo.yubico.com/php-yubico/Modhex_Calculator.php
For lazy people, type this in a shell and activate your Yubikey : read -p "Enter a YubiKey OTP: " s && echo 'The key id is' ${s:0:12}
Create a .yubico directory in your home, and create a file named authorized_yubikeys inside it. Fill this file with your unix username and Yubikey ID like that : username:yubikeyid
Next, create a id/secret couple for each server ou service you want to authenticate : https://upgrade.yubico.com/getapikey/
The ID returned after submitting the URL is the service ID, and the secret is the associated secret. Every pair ID/secret is unique.
You could use the same id/secret for every server you configure, but it is not intended for : you should use a different id/secret couple for every different server.
Log in to your server as root, and install libpam-yubico (from apt : apt-get install libpam-yubico).
And configure it : sudo dpkg-reconfigure libpam-yubico. When prompted, set the service ID in place of the N in id=N and the secret in place of the K in key=K.
Then apply the configuration with the command pam-auth-update.

That’s all ! Every PAM-compliant authentication will now ask for the Yubikey code to authenticate (as well as login and password). When login from SSH, juste activate your Yubikey after typing your password, before typing “enter”.

Warning : if you messed up the Yubikey configuration and are using “sudo” before every command, you will be locked outside your server ! After dpkg-reconfigure, if you checked “Yubico authentication”, it will ask for a Yubikey code every time a “sudo” authentication is required, so keep a root terminal opened to revert your changes.

Apache : globally configure HTTPS for all VirtualHosts

Mathieu — Sat, 16 Mar 2013 19:16:00 +0100

You want to configure “once and for all” HTTPs for all domains and sub-domains handled by your webserver, and you don’t want to redeclare the certificate in each VirtualHost. Here is the trick.

I run Debian. In a default Apache installation, the directory /etc/sites-enabled contains a file named 000-default which declares a default VirtualHost for HTTP.

You have to know that when Apache loads an entire directory of configuration files, the files are read in alphabetical order. So if you want to declare something before something else, you can cheat on its name in the loaded configuration. It is exactly what 000-default does.

In /etc/apache2/sites-available, you have a file named default-ssl. Edit this file to fit your needs (path to certificate, etc). Note that this certificate will be the same for all the domains hosted on your server. It’s what we want : only one configuration. If you are hosting multiple domains on the same server, the certificate will probably be invalid for at least one of your domains, and you should use mod_macro instead of a global HTTPs configuration.

Now, enable the website the common way : a2ensite default-ssl. Don’t restart Apache yet.

Rename the file default-ssl created in /etc/apache2/sites-enabled/ to 000-default-ssl.

Configure your other VirtualHost with a *:80 section and a *:443 section, as usual but without specifying certificate and SSL informations for VirtualHosts on *:443.

If you restart Apache, you will notice something like this :

_default_ virtualhost overlap on port 443

To get rid of these warnings, just add to your ports.conf, in the right section :

NameVirtualHost *:443
Listen 443 http

When you finally restart Apache, every VirtualHost declared as *:443 will use the certificate defined in 000-default-ssl without mentioning it.