Teletext still lives (just)

Teletext was developed in the 1970s in Britain as a way of sending information (text and basic colour graphics) in a PAL television signal.

The BBC implemented it as Ceefax (1974 to 2012), and numerous other broadcasters in PAL countries also used it. In Australia it was called Austext (1982 to 2009) and broadcast on Channel 7.

Apart from screens of information, the technology was also used to provide captions for TV programs (in Australia on page 801 on all networks).

In Australia, it ended in part because the original equipment was at end-of-life, no doubt combined with the rise of the Internet for getting that sort of information.

THE AUSTEXT SERVICE WILL CLOSE ON 30 SEPTEMBER 2009.

The Seven Network started providing test Teletext services in 1977, with live services commencing in 1982 in Brisbane and Sydney.

The Austext service today is still provided using the original 1970’s technology. This equipment has now reached the end of its lifespan.

Unfortunately,it is not possible to replace the existing Austext system with new equipment except at significant cost.

The BBC Micro and teletext

When the BBC Micro was introduced in 1981, this included a graphics mode (Mode 7) that natively supported teletext graphics. Given the computer only originally had 16-32 Kb of RAM, this mode using only 1 Kb was handy to have. It was mostly used by text-based programs, though there was the odd action game implemented in it — I remember a rendition of Space Invaders that used Mode 7.

In schools, BBC Micros could be networked together using the Econet system. A Teletext-like system was available that I think was called Eco-fax — we had that at my high school.

Less common, and only used in Britain, was a special Teletext adaptor, this could be used to download computer programs.

Teletext lives!

Teletext on broadcast television might be long gone, but there’s one place the technology is still used: in Australian racing.

Teletext displays in a TAB

Walk into any betting shop (this photo is from a TAB in Melbourne) and you’ll find these familiar text displays, with 8 colours, the capability of flashing and double-height text, and simple graphics, under the brand name “TabCorp Skytext”.

I have no idea how the signal is broadcast, but it’s definitely the same display technology. Nice to know it lives on, over 45 years since it was devised.

  • Ironically, this video from 2012 of highlights of 38 years of Ceefax isn’t playable on modern web browsers because it requires Flash

Taco Bill’s loyalty database hacked

A couple of weeks ago I noticed a suspicious-looking email that purported to be from Mexican restaurant chain Taco Bill.

I’m on their loyalty database (“Club Taco“), so I suspected their systems had been compromised.

Today they’ve confirmed it.

I’ll post the full statement, interspersed with some notes from me.

Data Breach – Taco Bill database

Taco Bill respects your privacy and values your ongoing business and, for this reason, would like to let you know, as a precautionary measure, about a data security incident that may involve your personal information.

On Friday, 22 September 2017, the Taco Bill email database managed by our external service provider was hacked by an unknown person or persons. This database contains personal information that you have provided to us when requesting to subscribe to our mailing system. This may include full name, postal address, email, phone number, date of birth, and additional linked account members’ details, if applicable (including spouse and/or childrens’ names).

By default, Club Taco asks for name and date of birth (the latter to send special offers on your birthday). Optional details include your address and phone number/s. I think — I hope — I didn’t enter those.

At present, they seem to have disabled the Club Taco joining page. Probably just as well.

The hacker uploaded approximately 1.75 million further subscribers to our database and then sent out two emails to our valued customers on our database and to the further 1.75 million subscribers that were uploaded. These emails do not appear to contain any viruses, but we recommend deleting them.

Sure, the email itself appeared to be clean. However, it did include a link to docx file on a hacked web site, multimixconcrete.com.au — hopefully they’ve figured out that they too were compromised.

From a trusted source:

At the time of writing, the multimixconcrete.com.au web site has been suspended by its ISP. It appears it belongs to a company in Western Australia.

We have been informed by our external provider that no information was copied off our database, however this does not mean that information may not have been copied.

Hedging their bets there a bit.

Taco Bill is undertaking a thorough review of the potentially affected database and its computers. We have also taken steps to protect your privacy and make sure this does not happen again, including scans of our computers, as well as changing our external service provider to provide us with faster response times on security issues, extra security measures for protection of your data and around the clock monitoring and alerts. We will let you know if there are any significant developments.

We suggest that you remain vigilant and, as a precautionary measure, review account statements and monitor credit reports. We also suggest you retain a copy of this letter for your records in case of any future concerns.

If you think your identity may have been stolen please immediately contact the relevant financial institution or company with which the account is held. We also suggest you immediately report any suspicious activity or identify theft to the proper law enforcement agency (for example, the police).

Please do not hesitate to contact Taco Bill head office on email admin@tacobill.com.au if you have any queries or require any additional information or assistance in relation to the above

If you are not satisfied with our response in resolving this issue, you can make a complaint to the Office of the Australian Information Commissioner, whose contact details are located at www.oaic.gov.au .

We sincerely apologise for this incident occurring. Taco Bill values your privacy and ongoing support of our business.

I wonder precisely what happened, and just how insecure their database was?

It’s a reminder that even big companies can mess up their security, and one should be wary of how much information we give them.

How to light the pilot on a Brivis Wombat 92 central heating unit

I’m lucky enough to have central heating in my house, and as the weather is cold in SE Australia at this time of year, we’ve been using it a bit.

Every few years a strong storm will blow out the pilot light. To fix it I climb up into the roof (fortunately I have an attic ladder fitted) and re-light it. Generally the effort involved to re-learn how to light it is more than the effort to actually do it.

So I’m doing like any good geek would: documenting it.

The unit is a Brivis Wombat 92 (I assume that means it’s a 1992 model). The instructions are written in tiny writing on a label attached to the inside of cover — so tiny it’s quite difficult to read while in the cramped roof space.

The steps are actually pretty quick and easy, as follows:

1. Make sure the heater control (eg in the house) is set to Off, and grab yourself a torch if you have to climb into the roof.

2. Take off the cover. On mine you pull it upwards, but I think my unit is actually mounted upside-down, judging from the logo on the side.

3. Find the dial. Turn it clockwise to the Off position.

4. Find the power point for the unit. The power cord on my unit leads to a power point about a metre away, mounted on a joist. Switch it off.

5. Wait a few seconds and switch it on again. You will hear a regular clicking sound – this is the heater trying to re-light. You’ve got about 20 seconds for the next step.

6. Turn the dial back to the Light position and press down on it. A couple of clicks later you should hear the pilot light.

7. That’s it! Put the cover back on. Enjoy the heat.

So basically, you’re turning it off then on again.

If it doesn’t work? I guess try it again. I know in 2013 mine wouldn’t re-light, and needed a service, but that’s perhaps not surprising for a 20 year old unit.

Good luck!

Securely run a low memory/low CPU Minecraft server

If you’ve got next to no memory and CPU available to run a Minecraft server, don’t fret. Cuberite is what you’re after. At them moment, Cuberite isn’t bug-free, nor indiscernible from a genuine Minecraft server, but it’s quite usable – and instead of needing 4GB+ of RAM, it needs less than 300MB. And it needs next to no processing power: some people run Cuberite on their Raspberry Pi and have plenty of CPU available.

I would at this point go on about how this is a significant point of difference between C++ and Java, but Java optimizes for something different to C++.  I got into an interesting discussion with Cathy about this after reading a question someone had about what Java was trying to be good at. I used to think that VB was the new COBOL, but clearly Java is the new COBOL; those Java programs are going nowhere, they’re verbose and easy to understand and maintain.

A point to note: The Minecraft protocols are bandwidth heavy, I found if I wanted to run a server at home I’d be able to have one, perhaps two players. Thus is Internet in Australia. Instead I’ve dropped this onto a free AWS VPS instance and bandwidth is no problem.

Still, it’s a random piece of software off the Internet, so we’re going to give it its own user account for our own safety. Let’s install the software:

curl -sSfL https://download.cuberite.org | sh
sudo mv Server /usr/local/cuberite
cd /usr/local/cuberite

Cuberite allows configuration through a web interface.  We now enable webadmin.ini
[User:admin]
; Please restart Cuberite to apply changes made in this file!
Password=yourstrongpassword
[WebAdmin]
Ports=8080
Enabled=1

Port 8080 is the alternative html port (http/https).  You could cd into webadmin and run GenerateSelfSignedHTTPSCertUsingOpenssl.sh and get https serving, but your browser will barf on the certificate. Instead, let’s use a LetsEncrypt certificate, one that we installed earlier. First we make our one-line shell script for running the daemon:

sudo useradd -c "Cuberite server" -f -1 -M -r cuberite
chown -R cuberite:`whoami` /usr/local/cuberite/
sudo nano /etc/init.d/cuberite.sh

#!/bin/sh
### BEGIN INIT INFO
# Provides: cuberite
# Required-Start: $local_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: cuberite
# Description: Cuberite server, a Minecraft server lookalike
### END INIT INFO
cd /usr/local/cuberite
sudo -u cuberite /usr/local/cuberite/Cuberite -d &

Next we set it going when the box starts up:

sudo chmod +x /etc/init.d/cuberite.sh
sudo update-rc.d cuberite.sh defaults

Before we can go to the website we need to allow user cuberite to get to the certificates:

sudo groupadd privkey_users
sudo usermod -aG privkey_users cuberite
sudo sudo chmod g+rx /etc/letsencrypt/live/
sudo sudo chmod g+rx /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/cert1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/chain1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/privkey1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/fullchain1.pem
sudo chown root:privkey_users /etc/letsencrypt/live/
sudo chown root:privkey_users /etc/letsencrypt/live/example.com/
sudo -u cuberite ln -s /etc/letsencrypt/live/example.com/cert.pem /usr/local/cuberite/webadmin/httpscert.crt
sudo -u cuberite ln -s /etc/letsencrypt/live/example.com/privkey.pem /usr/local/cuberite/webadmin/httpskey.pem

Changing these permissions doesn’t affect apache2’s ability to get them.
The reason we’ve used a group here is to allow both Cuberite and any other app (for example, exim) to access the private keys; just add any other user that needs to use the private keys to the privkey_users group.

Remember to punch a firewall hole for port 8080. Fire up Cuberite now:

sudo service cuberite restart

And check if that worked, there should be about one entry:

ps -aux | grep cuberitps -aux | grep cuberit

If not, you can check in the logs directory to see what’s wrong.

So now:

sudo lsof -i :8080
https://example.com:8080/

should be secure.  Note the https is mandatory, as your browser will use http if you fail to specify a protocol.

Windows WannaCrypt attack

This is interesting, and perhaps not unexpected: a vulnerability in Windows SMB 1 (used for shared drives) which was patched by Microsoft in March April, has been exploited.

It’s hit unpatched computers in numerous countries – most infamously, the UK’s National Health Service.

Despite what some Australian media is reporting, this tracker shows we are not immune — though it may be a reduced impact for now thanks to the weekend. Could be a different story on Monday.

For now it appears to have stopped thanks to someone finding a “kill switch”, but no doubt it or another version will hit again.

The lesson here for any of your computers that are connected to a network:

Patch them. Keep them up to date — preferably set them to automatically install patches.

If you’re using XP or older, Microsoft has just issued a patch, which you can get here.

You can also disable SMB 1 — note there are server and client portions, and that later versions of Windows make this a lot easier than earlier ones.

If you’re using Vista or older, find out about getting an upgrade. Vista patches stopped being issued earlier this year. You’ll be safe from this specific attack if you’re patched, but maybe not the next one. (Windows 7 keeps going until 2020.)

My assumption is that home users who use a broadband modem of some kind may not be at immediate risk this time from outside attack, since the modem can function as a basic firewall, but accidentally running an infected file from an email or web site could bring it in.

This attack has been serious, and other future ones will be too. So stay up to date, and stay safe.

  • Blatant plug: If you’re in southeast Melbourne and have no idea how to fix your computer, my brother-in-law runs this company that may be able to help: Bayside PC Services
  • In this blog post, Microsoft basically tells governments that they shouldn’t keep discovered vulnerabilities secret and exploit them for themselves (as the NSA did in this case, until that information was stolen) — that they should instead tell vendors so they can be fixed quickly. Difficult to argue with that.

Where do you wake up from a bed in Minecraft?

After issuing many /time set night commands, I can tell you the waking-location algorithm for Minecraft. This presumably also affects your spawn point.

Two locations are checked, and if they fail to select an acceptable location the pillow-location is used regardless of consequences of picking this location. An acceptable location is on the same level as the bed, and has two transparent-non-solid blocks above it (i.e. you will be standing next to the bed without your head or body embedded in something that’s killing you).

The process is the same for each of the two locations:

Sweep x-1 to x+1:
  Sweep z-1 to z+1:
    if the location is acceptable, we're done

The locations are checked in the order: pillow-part-of-bed, non-pillow-part-of-bed. The effect is:
From the Minecraft wiki:

For a bed to be usable as a spawn point, the player must be able to stand next to the bed at the same level as it. There must be a solid block at the same ‘floor’ level as the bed, with 2 transparent blocks of space (for example, air) for the player to stand in, in one of the ten blocks that surround the bed. It doesn’t matter if the bed itself has blocks above it.

Netgear Stora upgrade v3: 2-disk-JBOD to 1-disk-JBOD

So, we’re butting heads up against the storage capacity of our Netgear Stora again (93% full). The NAS currently has 2 x 2TB drives and no more free bays to drop drives into, so whatever the next arrangement is it has to involve getting rid of at least one of the current drives. The Stora is currently backed up to an external drive enclosure with a 4TB drive mounted in it. Other things are also backed up on that external drive, so it’s more pressed for space than the Stora.

So here’s the plan:

  • collect underpants
    This was a flippant comment, but it’s upgrade season and we recently acquired a computer second hand, which had an i5-3470S CPU, the most powerful thing in the house by a significant margin. I wanted the dual Display Port outputs, but unfortunately it could only be upgraded to 8GB of RAM, so instead the CPU got swapped into our primary desktop (and a graphics card acquired to run dual digital displays). Dropping in a replacement CPU required replacing the thermal grease, and that meant a rag to wipe off the old grease, thus the underpants.
  • backup the Stora to the 4TB drive
  • acquire a cheap 8TB disk because this is for backing up, not primary storage
  • clone the 4TB drive onto it using Clonezilla
  • expand the cloned 4TB partition to the full 8TB of drive space
    Well, that didn’t work.  Clonezilla didn’t seem to copy the data reliably, but admittedly I was running a stupidly old version.  Several hours of mucking around with SATA connectors and Ubuntu NTFS drivers later, I gave up and copied the disk using Windows.  It took several days, even using USB3 HDD enclosures, which is why I spent so much time mucking around trying to avoid it.
  • backup the Stora to the 8TB drive
  • remove the 2 x 2TB drives from the Stora
  • insert the 4TB drive into the Stora
  • allow the Stora to format the 4TB drive
  • pull the 4TB drive
  • mount the 4TB and 2 x 2TB drives in a not-otherwise-busy machine
  • copy the data from the 2 x 2TB drives onto the 4TB drive
  • reinsert the 4TB drive into the Stora
  • profit!

And, by profit, I mean cascade the 2TB drives into desktop machines that have 90% full 1TB drives… further rounds of disk duplication ensue. 1TB drives then cascade to other desktop machines, further rounds of disk duplication ensue.

At the end of this process, the entire fleet will have been upgraded. But the original problem of butting heads against the Stora will not have been addressed; this will hopefully a simple matter of dropping another drive in.

The last time we did this, we paid $49.50/TB for storage.  This time around, it was $44.35; a 10% drop in storage prices isn’t anything to write home about in a four-and-a-half year window.

Trustworthy email: authentication using exim4, SPF, DKIM and DMARC

The email authentication technologies we’re about to implement are, according to the authentication authorities, all you need to be regarded as being from your domain when you send email, and someone else not being from your domain.  Effect: your emails can be considered trustworthy by email receivers who use these technologies. If they don’t use these technologies, they can’t tell.

At the very least, Google will be less likely to think your email is spam.

PTR record

A PTR record can be obtained from your host’s nameserver – it’s a reverse DNS record for your IP address. If the PTR record points at ec2-23-65-53-221.ap-southeast-2.compute.amazonaws.com rather than example.com (your domain), and you’re claiming to be sending mail from example.com, what’s the email recipient meant to think?

host 23.65.53.221

will tell you what the host for that IP is. Lodge a ticket with your hosting provider and get that PTR record changed to example.com. This might take about a day.

SPF record

Create a Sender Policy Framework record on your nameserver:

TXT @ "v=spf1 a mx -all"

This says “for my domain, I will only send email from IP addresses listed on the nameserver”.  Nameserver changes take time to propagate.

After your nameserver changes have propagated, you can go to https://dmarcian.com/spf-survey/ to check out if you got it right.

DKIM

DomainKeys Identified Mail is where things get more involved.  We’re doing this on a Debian Linux, like Ubuntu for exim4. We’re making our signing key 2048 bits, which is long enough to make life slightly unpleasant for us. Fortunately for you I’ve written a bash script that outputs the TXT record we need to create on the nameserver – because some nameservers (I’m looking at you, Gandi) can’t hold “long” strings – it’s broken into “small” strings:

sudo apt install openssl
cd /etc/exim4
sudo openssl genrsa -out dkim.private 2048
sudo openssl rsa -in dkim.private -out dkim.public -pubout -outform PEM
echo $(echo $(date -u +%Y%m%d && echo '.domainkey.example.com') | sed -e 's/[ ]//g' && echo $(echo ' TXT "v=DKIM1; p="' && echo $(grep 'PUBLIC KEY' -v dkim.public) | sed -e 's/[ ]//g' | fold -w200 | sed -e 's/\(.*\)/"\1"/g'))

which gives something like
20170419._domainkey TXT “v=DKIM1; p=” “MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvCNqU0Njd4YQ4e89T3FNc+uyOS2JwUqynGk7uwcSYHjIE2MGRuTxi56s4JgPKSnCVlBkJlUnXQHXFp2UGnLm8SADtjRMfWwpNxz6TmzXBpMnNZV1zvuoBBdcxh0Qg1TtCSACtWM6ehml0BmOHVA8Ippqj9iRlP2HMjuVMxZXewN9eJl”
“c6zsyOwQPvVKpJ+Rdvr+pPkDztAVTw7mNSeyy+TL6O/3L9sl7A19Yx8jLHKuGUh9LutVuv1VP16e7GwlnA3Zqn5C1jyY5Qvr2SEHZMcE3VzD7XKZtZWbpkGh+A5S15NrOH4k9tbVfNbjft6Y1jUJRTT+4DD0ZEVlr4zO+WQIDAQAB”

That all goes into one nameserver TXT record, spaces and all.  The world will join up the ” ” and get one big string. Note the bold number up there? That’s the selector. That a number needs to get larger with each new key.  Periodically you’re going to have to reissue your key because security.  You know what gets larger as time goes by?  The date.  Use the date.  If you screw up, use tomorrow’s date, etc.

Once you’ve got our public key out to the public via our public nameserver, we need to get exim to sign the payloads:

sudo nano conf.d/main/01_exim4-config_listmacrosdefs

After the line CONFDIR = /etc/exim4, add:

#DKIM loading
DKIM_CANON = relaxed
DKIM_DOMAIN = ${sender_address_domain}
DKIM_PRIVATE_KEY = CONFDIR/dkim.private
DKIM_SELECTOR = 20170419

and reload the mail server

sudo service exim4 restart

After an appropriate delay for nameserver propagation, use https://protodave.com/tools/dkim-key-checker/?selector=20170419&domain=example.com to check your work.
If that works out, mailto:check-auth@verifier.port25.com from example.com to ensure everything checks out:

echo -e "Test my DKIM plz\nMsg Body\n.\n\n" | mail -v check-auth@verifier.port25.com

DMARC

Domain-based Message Authentication, Reporting and Conformance is where the wheels can come off if you screwed anything up.  We’re going to set things up so that when you screw it up, computers scold you rather than putting your emails in the bin.

You will need to create two dmarc reporting accounts.  Servers will email you a (surprisingly detailed) report card on how you’re doing with your implementation. It’s best if these accounts are on the same domain, because technically you need to be or it’ll be ignored (Google will happily mail reports off-domain even if the other domain hasn’t said that’s okay).  Yours are dmarc_failures@example.com and dmarc_summary@example.com, according to the following nameserver entry:

_dmarc.example.com. 1800 IN TXT "v=DMARC1;p=none;pct=100;ruf=mailto:dmarc_failures@example.com;rua=mailto:dmarc_summary@example.com"

none is the consequence for screwing up. none is where we’ll start at, and see what the reporting records say to us.  After a while, you’ll be comfortable that everything is ticking along nicely, and you’ll up the consequent to quarantine (shove it in spam) or reject (burn it).

After your nameserver changes have propagated, you can go to https://dmarcian.com/dmarc-inspector/ to check out if you got it right.

As a human, to read the records sent to you, upload the files to https://dmarcian.com/dmarc-xml/

Making a captcha deamon for spamgourmet installations

For those of you following along at home, this is part of a cookbook style instruction set for getting spamgourmet going, but because of screwed up permission logic I can’t post this section there.

The captcha is for validating humanity when creating spamgourmet accounts. We’re going to limit what parts of the OS it can tromp over:

sudo useradd -c "captcha server for spamgourmet" -f -1 -M -r captcha
sudo /bin/mkdir -p /var/www-spamgourmet/captchasrv/
sudo chown -R captcha /usr/local/lib/spamgourmet/captchasrv/
sudo chown -R captcha /var/www-spamgourmet/captcha

Now we make our one-line shell script for running the daemon

sudo nano /etc/init.d/captcha.sh

#!/bin/sh
### BEGIN INIT INFO
# Provides:          captchasrv
# Required-Start:    $local_fs $network
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: captchasrv
# Description:       captcha daemon for spamgourmet
### END INIT INFO
sudo -u captcha perl /usr/local/lib/spamgourmet/captchasrv/captchasrv.pl &

Next we get it going

sudo chmod +x /etc/init.d/captcha.sh
sudo update-rc.d captcha.sh defaults

And check if that worked, there should be about four entries:

ps -aux | grep captc

Now the captcha server will start whenever the computer starts.

How to to install the Crypt::Eksblowfish::Bcrypt module, and Crypt::Random

Have you gotten the error
Can't locate Crypt/Eksblowfish/Bcrypt.pm in @INC (you may need to install the Crypt::Eksblowfish::Bcrypt module)
and wondered what to do? Wonder no more!

sudo apt install libcrypt-eksblowfish-perl

and perhaps

sudo apt install libdigest-bcrypt-perl

What about
Can't locate Crypt/Random.pm in @INC (you may need to install the Crypt::Random module)
Easy!

sudo apt install unzip make gcc
wget http://search.cpan.org/CPAN/authors/id/I/IL/ILYAZ/modules/Math-Pari-2.01080900.zip
cd Math-Pari-2.01080900/
perl Makefile.PL
sed -i 's/CLK_TCK/CLOCKS_PER_SEC/g' pari-2.1.7/src/language/init.c
make
make test
sudo make install
cd ..
wget http://search.cpan.org/CPAN/authors/id/V/VI/VIPUL/Crypt-Random-1.25.tar.gz
tar zxvf Crypt-Random-1.25.tar.gz
cd Crypt-Rando1.25.tar
perl Makefile.PL

Easy! Only takes a few hours if you don’t know what you’re doing.

Installing a secure Apache webserver to run Perl

So, you want to run Perl on the web, because it’s the 90s all over again. You want HTTPS, because… no, there’s no because.  You want HTTPS.  Who wouldn’t?  Here’s what you do on a Debian Linux such as Ubuntu:
sudo apt-get install apache2 libapache2-mod-perl2
mod-perl is an Apache module that allows Perl programs to be executed from Apache.

Our goal is to get /var/www/html/index.pl running at http://www.example.com/index.pl:

#!/usr/bin/perl
print "Hello World"

Disable the default Apache virtual host:

sudo a2dissite 000-default.conf

Create an example.com.conf file in /etc/apache2/sites-available with your text editor, replacing instances of example.com with your own domain name in both the configuration file and in the file name /etc/apache2/sites-available/example.com.conf

<VirtualHost *:80>
     ServerName example.com
     ServerAlias www.example.com
     ErrorLog ${APACHE_LOG_DIR}/error.log
     CustomLog ${APACHE_LOG_DIR}/access.log combined
     <Directory /var/www/>
              Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
              AllowOverride None
              AddHandler cgi-script .pl
              Require all granted
     </Directory>
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
     ServerName example.com
     ServerAlias www.example.com
     ErrorLog ${APACHE_LOG_DIR}/error.log
     CustomLog ${APACHE_LOG_DIR}/access.log combined
     <Directory /var/www/>
              Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
              AllowOverride None
              AddHandler cgi-script .pl
              Require all granted
     </Directory>
</VirtualHost>
</IfModule>

If you have multiple sites, you’ll want to do things with DocumentRoot to isolate them from each other. But that’s for another post.

You might add in DirectoryIndex /index.pl to make http://www.example.com/ execute your program.

The Directory section above allows you to isolate executable code from served code, which is good practice. For this example we’re dumping the executable in with everything else, which is questionable.

Repeat this process for any other domains you host.

sudo a2ensite example.com.conf
sudo ln -r -s /etc/apache2/sites-available/example.com.conf /etc/apache2/sites-enabled/example.com.conf
sudo service apache2 restart

Punch holes in your firewall for ports 80 and 443.  Navigate to http://www.example.com/index.pl to check all is okay. You ought to see Hello World displayed for your website.

Having security used to be a pain.  SSL certificates signed by a recognised CA cost money, and then you’d have to keep them up to date, and there wasn’t process automation, so you’d do all that stuff by hand.  LetsEncrypt address all these problems, handing out free certificates and scripted everything.

Now it’s time for the S part of HTTPS:
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-apache
sudo certbot --apache

certbot renew
If that works, we’ll automatically renew our 90-day certificates every month:
echo '@monthly root /usr/bin/certbot renew >> /var/log/letsencrypt/letsencrypt-auto-update.log' | sudo tee --append /etc/crontab

Done.  You’ll never have to worry about certificates again. Now alter your Apache sites-available file (look in /etc/apache2/sites-available/) to include the (optional) redirect HTTP to HTTPS and the mandatory location of the SSL certificates:

<VirtualHost *:80>
....
# Only allow HTTPS
RewriteEngine on
RewriteCond %{SERVER_NAME} = example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
...
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now make the secure version live, and in the process the insecure one… shy? When a request is made for a http page, like http://example.com/index.html, the response will be “Here’s https://example.com/index.html where what you asked for has moved to… forever!”:
sudo service apache2 restart
Now requesting http://www.example.com/index.pl ought to deliver you to https://www.example.com/index.pl

Install exim4 STARTTLS using a free LetsEncrypt certificate

Here we are on a Debian Linux, such as Ubuntu and we want to run a mail server. Exim4 is currently the most popular email server, but getting it up and working for free is a hassle – who wants to pay for a SSL certificate, on an ongoing basis? And then there’s the maintenance of the security of it – constant renewal, renouncing and re-installation of the certificates.

Wherever you see example.com, swap in your Fully Qualified Domain Name. That may be mail.example.com
It’s assumed you’re not logged in as root, but user ubuntu
Wherever you see 1.2.3.4, swap in your machine’s local IP address, from
ifconfig | grep "inet addr" | grep -v "127.0.0.1"

Security is all handled automatically by LetsEncrypt’s certbot. I’ll let you look that one up yourself. Run it up and get your certificate for example.com

Once you’ve got that handled, punch a hole in your firewall so that port 25 can get through from the outside world to your machine. Be aware: the outside world is filled full of botnets trying to hack into your machine.  After installing exim, keep an eye on the logs in /var/log/exim4/ for a while.

Let’s install exim4:
sudo apt-get install exim4
sudo dpkg-reconfigure exim4-config

  • pick “Internet site”
  • system mail name is example.com
  • IP address is 1.2.3.4 (the one returned by ifconfig, not the externally accessable one)
  • Other destinations: example.com
  • No relays
  • No smarthost
  • No Dial-on-Demand
  • mbox format (or whatever)
  • Split the files
  • ubuntu for postmaster mail

Check we’re now running a mail server:
sudo netstat -napt
should show
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 1.2.3.4:25 0.0.0.0:* LISTEN 25700/exim4

Now we have a mail server, the world needs to find it. Check your nameserver setting to ensure mail is destined this machine.  You probably want only one MX record.

Check the Internet can send mail to our server. After allowing for the appropriate propagation delay for your nameserver changes, use gmail or something to send an email to ubuntu@example.com – you should be able to read it by typing
mail

Now it’s time to enable MTA-MTA link encryption for secure transport of mail, by enabling STARTTLS on exim4 using our LetsEncrypt certificate
sudo nano /etc/exim4/conf.d/main/03_exim4-config_tlsoptions
Enable STARTTLS by adding/setting in the tlsoptions section:
MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTKEY = no

before any of the IF shenanigans. Also add/replace pointers to the certificates:
tls_certificate = /etc/letsencrypt/live/example.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/example.com/privkey.pem

The MAIN_TLS_CERTKEY = no entry fixes an exim4 log message
2017-04-16 09:13:24 TLS error on connection from your.home.ip.com (IcePlanet) [5.6.7.8] (cert/key setup: cert=/etc/exim4/exim.crt key=/etc/exim4/exim.key): Error while reading file.
You will see this when testing with swaks:
$ swaks -a -tls -q HELO -s example.com -au test -ap '<>'
=== Trying example.com:25...
=== Connected to example.com.
< - 220 your.vps.host.com ESMTP Exim 4.86_2 Ubuntu Sun, 16 Apr 2017 09:13:24 +0000 -> EHLO IcePlanet
< - 250-your.vps.host.com Hello your.home.ip.com [5.6.7.8]
STARTTLS
< ** 454 TLS currently unavailable *** STARTTLS attempted but failed -> QUIT
< - 221 your.vps.host.com closing connection
=== Connection closed with remote host.

Allow exim (which when running runs as user Debian-exim) to get to the certificates:

sudo groupadd privkey_users
sudo usermod -aG privkey_users Debian-exim
sudo sudo chmod g+rx /etc/letsencrypt/live/
sudo sudo chmod g+rx /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/cert1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/chain1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/privkey1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/fullchain1.pem
sudo chown root:privkey_users /etc/letsencrypt/live/
sudo chown root:privkey_users /etc/letsencrypt/live/example.com/

Changing these permissions doesn’t affect apache2’s ability to get them.
The reason we’ve used a group here is to allow both exim and any other app (for example, a secondary service that wants to use 8080 to serve up a configuration page) to access the private keys; just add any other user that needs to use the private keys to the privkey_users group.

These permission changes prevent the following error message in your log file:
2008-06-03 08:27:35 TLS error on connection from me.at.home.com ([1.2.3.4]) [5.6.7.8] (cert/key setup: cert=/etc/ssl/certs/server.pem key=/etc/ssl/private/server.key): Error while reading file.

Restart the service and the TLS settings ought to be working
sudo service exim4 restart
Test STARTTLS is working from another machine
swaks -a -tls -q HELO -s example.com -au test -ap '<>'
There shouldn’t be any obvious complaining.

Done!