msgbartop
MAC OS X, Linux, Windows and other IT Tips and Tricks
msgbarbottom

02 May 18 Configuring Domain Relaying with ISPConfig 3.1.xx

Intention:
Redirect (reroute) specific email addresses via, for example, an SMTP service:

Steps:
– Enter the destination domain in the Advanced Routing Table (Email ==> Email Accounts/Email Routing)
– Enter the same destination domain in the (Email ==> Global Filters / Relay Recipients) as @domain

Example:
eg. rerouting all emails of destination domain mydomain.com via a relay server (relay.myserver.com)

(Email ==> Email Accounts / Email Routing)
Select ‘Add new Transport’
Fill in the fields:
Server: (Select the server)
Domain: mydomain.com
Type: (select smtp)
No MX lookup: (leave unchecked)
Destination: relay.myserver.com
Sort by: 1
Active: (Checked)

(Email ==> Global Filters / Relay Recipients)
Select: ‘Add new relay reciepient’

Fill in the fields:
Server: (Chose the server)
Relay recipient: @mydomain.com
Active: (Checked)

02 May 18 No Type list in ISPConfig 3.1.11

Problem:
The brand new version of ISPConfig 3.1.11 when I add or modify an email transport, no value is displayed anymore on “type”.

Solution:
Ref: https://git.ispconfig.org/ispconfig/ispconfig3/issues/4924
Edit /usr/local/ispconfig/interface/web/mail/mail_transport_edit.php
Change this line:
$app->tpl->setVar($rec, null, true);
to this:
$app->tpl->setVar($rec);
and should work again.

02 Jan 18 Install CERTBOT in Ubuntu-16-04-xenial and Debian Stretch

Intro: Here is a 1-to-1 copy of the article on how to install certbot in Ubuntu 16.04 and Debian Stretch

Ubuntu 16.04 HOWTO:

Install
On Ubuntu systems, the Certbot team maintains a PPA. Once you add it to your list of repositories all you’ll need to do is apt-get the following packages.
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot

Advanced Get Started
Certbot supports a number of different “plugins” that can be used to obtain and/or install certificates.
Since your server architecture doesn’t yet support automatic installation you’ll have to use the certonly command to obtain your certificate.
$ sudo certbot certonly
This will allow you interactively select the plugin and options used to obtain your certificate. If you already have a webserver running, we recommend choosing the “webroot” plugin.
Alternatively, you can specify more information on the command line.
To obtain a cert using the “webroot” plugin, which can work with the webroot directory of any webserver software:
$ sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is
This command will obtain a single cert for example.com, www.example.com, thing.is, and m.thing.is; it will place files below /var/www/example to prove control of the first two domains, and under /var/www/thing for the second pair.
Note:
To use the webroot plugin, your server must be configured to serve files from hidden directories. If /.well-known is treated specially by your webserver configuration, you might need to modify the configuration to ensure that files inside /.well-known/acme-challenge are served by the webserver.
To obtain a cert using a built-in “standalone” webserver (you may need to temporarily stop your existing webserver, if any) for example.com and www.example.com:
$ sudo certbot certonly --standalone -d example.com -d www.example.com
Automating renewal
The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire. Since Let’s Encrypt certificates last for 90 days, it’s highly advisable to take advantage of this feature. You can do automatic renewal for your certificates by running this command:
$ sudo certbot renew

Debian Stretch(9.0) HOWTO:

Install
Since Certbot is packaged for your system, all you’ll need to do is apt-get the following packages.
First you’ll have to follow the instructions here to enable the Stretch backports repo, if you have not already done so.
For this run:
$ sudo echo "deb http://ftp.debian.org/debian stretch-backports main" >> /etc/apt/sources.list
$ sudo apt-get update
$ sudo apt-get install certbot -t stretch-backports

Advanced Get Started
Certbot supports a number of different “plugins” that can be used to obtain and/or install certificates.
Since your server architecture doesn’t yet support automatic installation you’ll have to use the certonly command to obtain your certificate.
$ sudo certbot certonly
This will allow you interactively select the plugin and options used to obtain your certificate. If you already have a webserver running, we recommend choosing the “webroot” plugin.
Alternatively, you can specify more information on the command line.
To obtain a cert using the “webroot” plugin, which can work with the webroot directory of any webserver software:
$ sudo certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is
This command will obtain a single cert for example.com, www.example.com, thing.is, and m.thing.is; it will place files below /var/www/example to prove control of the first two domains, and under /var/www/thing for the second pair.

Note:
To use the webroot plugin, your server must be configured to serve files from hidden directories. If /.well-known is treated specially by your webserver configuration, you might need to modify the configuration to ensure that files inside /.well-known/acme-challenge are served by the webserver.

To obtain a cert using a built-in “standalone” webserver (you may need to temporarily stop your existing webserver, if any) for example.com and www.example.com:
$ sudo certbot certonly --standalone -d example.com -d www.example.com
Automating renewal
The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire. Since Let’s Encrypt certificates last for 90 days, it’s highly advisable to take advantage of this feature. You can do renewal for your certificates by running this command:
$ sudo certbot renew

21 Dec 17 Blocking reception of full TLDs

Intro:
Lately I was receiving a lot of spam from a ‘.date’ TLD sources and wanted to block all these emails using Postfix.
Here is a solution found at: https://serverfault.com/questions/728641/blacklisting-tld-in-postfix/728658

Steps:
Install the Postfix PCRE dictionary
apt-get install postfix-pcre
Configure postfix
postconf -e smtpd_sender_restrictions=pcre:/etc/postfix/rejected_domains
postconf -e reject_unauth_destinations=pcre:/etc/postfix/rejected_domains

Edit the new file /etc/postfix/rejected_domains with the following content:
/\.date$/ REJECT All Date Domains
Reload Postfix
service postfix reload

11 Dec 17 OpenDKIM doesn’t start after Upgrade from Jessie to Stretch

Introduction:
After having done a dist-upgrade fo Jessie to Stretch OpenDKIM didn’t start any more.
After research I found the answer which worked for me in this site:
https://serverfault.com/questions/847435/cant-change-opendkim-socket-in-debian-stretch-in-etc-default-opendkim

INFO:
I’m using the ‘inet’ socket for the communication between Postfix and OpenDKIM at port 12345.
eg. My config in of OpenDKIM in Postfix:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = inet:localhost:12345

Solution found in the above web site:
/lib/opendkim/opendkim.service.generate
systemctl daemon-reload
service opendkim restart

Note: There are other solutions for the ones that use other kind of communication sockets for the communication between Postfix and OpenDKIM found in the same above site.

Solution: Regenerate the proper

02 Sep 17 Transferring IMAP account mails and folders to another IMAP account on another server

Introduction:
The other day I was asked to install a completely new email server and transfer all the email accounts from the old mail server to the new one. I noticed that since the new mail server was using a different mail INBOX format I had to do some research and found this really good tool to do exactly what I needed called: imapsync

Installing the tool:
This tool programmed in Perl and is not free. It can be bought at http://imapsync.lamiral.info/.
Note: It does a great job and it’s really worth its price when you think of the time and hassle saved by using it.

Using the tool:
Example 1: Copying all the mails in folder INBOX from jim account on localhost to another server with the same credentials:
– First we do a dry-run to see what will be transferred when I run it normally:

imapsync --dry \
--host1 localhost --user1 jim --password1 'secret1' --folder INBOX --tls2 \
--host2 mail.myserver2.com --user2 jim --password2 'secret1' --nofoldersizes --nofoldersizesatend

Example 2: Copying all the mails and folders(no dry-run) from account martin@myserver1.com on localhost to a new account on another server with different credentials:
imapsync \
--host1 localhost --user1 martin@myserver1.com --password1 secret1 \
--host2 mail.myserver2.com --user2 martin@myserver2.com --password2 secret2

16 May 17 Hardening the SSL security in Apache, Dovecot and Postfix

Introduction:

After having gotten a report from OpenVAS that my SSL security level of the mail server were medium, I looked for ways to improve this.
I found very good sites which helps me making these improvements:
https://weakdh.org/sysadmin.html
https://wiki.dovecot.org/SSL/DovecotConfiguration
https://bettercrypto.org/static/applied-crypto-hardening.pdf
Based on this site and extending to cover dovecot mail service here is the result:

Hardening Apache:

In /etc/apache2/mods-available/ssl.conf
Change the following parameters as follows:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DH+3DES:!RSA+3DES
SSLHonorCipherOrder on

Hardening Dovecot:

Note: you should have openssl >=1.0.0 dovecot >=2.1.x required, better dovecot >=2.2.x because of ECDHE support Dovecot tryies to use PFS by default, so besides the enabled SSL almost no actions are required change the log settings to see the cipher, grep for a login_log_format_elements in dovecot configs and add %k to it
eg:
login_log_format_elements = "user=< %u> method=%m rip=%r lip=%l mpid=%e %c %k"
Configure the allowed ciphers. Server side enforcement works only for dovecot >=2.2.6
In /etc/dovecot/conf.d/ssl.conf
Change some parameters as follows:
ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
#only for dovecot >=2.2.6, enforce the server cipher preference
ssl_prefer_server_ciphers = yes
#disable SSLv2 and SSLv3
ssl_protocols = !SSLv2 !SSLv3

Add the following parameter:
ssl_dh_parameters_length = 2048
Delete the file /var/lib/dovecot/ssl-parameters.dat
and restart Dovecot service:
service dovecot restart
Dovecote seeing that the Diffie Hellman parameters are assigned to be 2048 bits long and that its file is just been deleted, will regenerate a new one in the background.

Hardening Postfix

In /etc/postfix/main.cf
Change or add the following configuration parameters:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_dh1024_param_file=/etc/ssl/dh2048.pem

Generate a new Diffie Hellman parameters file as follows:
openssl dhparam -out /etc/ssl/dh2048.pem 2048

24 Feb 17 Whitelisting Hosts in Postfix/Amavis

Introduction:
I have an email server with very strong spam filtering and every now and then it does see the emails that I send from our own networks as SPAM.
In order to bypass the SPAM scanner for those networks without bypassing the virus scanning of Amavis I found these instructions in Internet at:
http://verchick.com/mecham/public_html/spam/bypassing.html#1

Allow clients on my internal network to bypass scanning by using the ‘MYNETS’ policy bank. You can use the built in ‘MYNETS’ policy bank to allow clients included in $mynetworks. Let’s assume you allow all (or most) clients on your internal network to send outbound mail through your spamfilter.
The IP addresses of these clients are included in Postfix’ $mynetworks in main.cf:
mynetworks = 127.0.0.0/8 !192.168.1.1 192.168.1.0/24
In /etc/amavis/conf.d/50-user @mynetworks determines which clients will use the ‘MYNETS’ policy bank:
@mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10
!192.168.1.1 192.168.1.0/24 );

And you would configure the ‘MYNETS’ policy bank as desired:
Also added to /etc/amavis/conf.d/50-user
$policy_bank{'MYNETS'} = { # clients in @mynetworks
bypass_spam_checks_maps => [1], # don't spam-check internal mail
bypass_banned_checks_maps => [1], # don't banned-check internal mail
bypass_header_checks_maps => [1], # don't header-check internal mail
};

When using the “MYNETS’ policy bank, you must use *_send_xforward_command in master.cf which enables forwarding of the client’s IP address to amavisd-new.:
smtp-amavis unix - - n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

(or)
lmtp-amavis unix - - n - 2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

31 Mar 16 Fixing Spamassassin in Debian Jessie(8)

Introduction:
For a long time under Debian Wheezy Spamassassin was running quite well until I upgraded the system to Jessie. That is when Spamassassin(spamd) started to crash every now and then without giving much reasons why.

Cause of error message:
Looking in the system logs(/var/log/syslog) I found the following error:
spamd[7490]: util: refusing to untaint suspicious path: "/${SAHOME}"
I’m not sure if this is the cause of the crashes but it certainly doesn’t help. So I figured I should first try to solve this error first. According to this site since the Spamassassin is now started via ‘systemd’ the variables set in the init config file (/etc/default/spamassassin) are not expanded and they are passed on ‘as-is’ on the command line for starting spamd process. eg.
SAHOME="/var/lib/spamassassin/"
OPTIONS="--create-prefs --max-children 5 --username spamd --helper-home-dir ${SAHOME}"

Solution:
Since this file will not be overwritten during updates the suggestion was to write the value of this variable directly in the OPTIONS line in (/etc/default/spamassassin) as follows:
OPTIONS="--create-prefs --max-children 5 --username spamd --helper-home-dir /var/lib/spamassassin/"
Now at least this error doesn’t occur any more and time will tell if the crashes of spamd are still happening.

09 Mar 16 Testing SSL Connections with SSLyze, Nmap or OpenSSL

Introduction:
OpenSSL is a great tool to check SSL connections to servers. The difficulty here is when one want a full scan of all possible SSL Cyphers and protocols used by a server. That is where SSLyze comes in handy. This tool is a Python script which will scan the target host/port for SSL handshake and report what works/support and what not. Unfortunately this lovely tool is not included in the Ubuntu/Debian distributions, and this is where this post comes handy.

IMPORTANT: Besides executing all the tests below one thing very important (as noted in the This link) is to upgrade OpenSSL to the latest version as follows:
OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

SSLyze

Installing the dependencies and tool
cd /root/bin
wget https://github.com/nabla-c0d3/sslyze/archive/0.13.4.tar.gz
tar fvxz 0.13.4.tar.gz
apt-get install python-pip python-dev
pip install nassl

Using SSLyze
python /root/bin/sslyze-0.13.4/sslyze_cli.py --regular www.itmatrix.eu:443

NMAP

Scanning the full server for weaknesses including weak SSL Versions using NMAP.
Note: This operation can take a long time to execute.
apt-get install nmap
nmap -sV -sC www.itmatrix.eu

OR better(for checking the HTTPS,SMTPS,IMAPS,POP3S)
nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.itmatrix.eu

OpenSSL

Checking the SSL connection with OpenSSL
echo 'q' | openssl s_client -host www.itmatrix.eu -port 443
Note: In this above case since the SSLv2 support is normally disabled for OpenSSL in Debian/Ubuntu distributions, you will not be able to see if the server is supporting it. To overcome this and enable SSLv2 support(for your testing Linux) then follow the instructions in this site:
http://www.hackwhackandsmack.com/?p=46

NOTE:
For more information regarding protection against DROWN(SSLv2) or POODLE(SSLv3) attacks see:
https://drownattack.com
http://www.softwaresecured.com/2016/03/01/how-to-confirm-whether-you-are-vulnerable-to-the-drown-attack/
http://www.mogilowski.net/lang/de-de/2014/10/23/disabling-sslv3-for-poodle-on-debian/
https://www.owasp.org/index.php/Testing_for_Weak_SSL/TLS_Ciphers,_Insufficient_Transport_Layer_Protection_%28OTG-CRYPST-001%29
https://zmap.io/sslv3/