With the recent increase in home working, corporates have been beefing up their IT security measures. What was once the comparatively small attack vector of a fraction of the workforce occasionally connecting from home now represents a huge gaping hole. The simplest way in which corporates can protect against this enlarged attack surface is to mandate that several key components of connecting user’s systems meet certain criteria. These are usually, but not limited to; having an operating system that is up to date, installing a firewall and activating an anti-virus solution.

This is where the title of this article comes in. These criteria are as you will see, very Windows centric. One can also stretch these to apply to a Mac, but when it comes to Linux these checks become very hazy indeed. For example, what qualifies as a firewall? IP tables on my router? My local machine? Something else? Also the operating system – how can this be checked? There are so many out there and so many are secure, even on old versions thanks to back-ports and patches. A murky world indeed.

Fortunately I can, for one vendor product at least, F5, offer some insight into how to configure your local machine so that their checks will pass and permit remote connections. F5 end point inspection is commonly used in web accessible gateways that go on to permit Citrix style remote desktop access. By definition therefore this will cover the majority of users who work on either remote fixed machines or a VDI type setup.

Operating System

I was unable to get F5 to reject access on account of the operating system or how up to date it was, so I assume that any common Linux distribution that is running a supported version and has been reasonably recently updated for security and other patches will be permitted by the end point inspection process

Firewall

Neither my iptables rules on my local machine nor those present on my routers were sufficient to pass the end point inspection check for a firewall. My gateway router also has various filters based on packet inspection for additional protection but these also seemed to have little effect. The only way I could satisfy this failing test was to activate UncomplicatedFirewall. Now I could have gone to the lengths of figuring out what feature(s) of UFW were cogent to the test but this seemed like too much hassle. I only need SSH access to my local machine from others within my network and this is a simple enough rule to setup in UFW.

Anti Virus

Anti virus in the Linux space is a hotly debated topic and I’m not about to delve deeply into this here. Suffice it to say that most solutions focus heavily on manual or semi-automated scanning for vulnerabilities that are largely Windows centric. In other words, ensuring that no Windows viruses are transmitted to an unwitting user of a Linux mail server. What this means is that, for the most part, the end user of a Linux desktop probably doesn’t need an anti virus solution. Such arguments however are of absolutely no use to passing the “computer says no” bot of the f5 end point inspection tool.

My initial approach was to install ClamAV. This is free and works nicely for my mail server and other similar applications that would do well having some protection in place for Windows users. F5 *did* detect this solution was in place, however it then failed a further check – the one for real time protection. This is quite right – by default ClamAV doesn’t have such protection and indeed servers using it will make a call to invoke the scan on incoming files as applicable. ClamAV does have documentation regards enabling real time protection but unfortunately, despite following this process and seeing it in operation on my machine, the test still wouldn’t pass. Having spent too much time on this approach with no success I looked to other options.

Two commercial offerings stood out as both having free Linux solutions and real time protection – Comodo and Sophos. I tried Comodo first but after a lot of tinkering couldn’t get the real time protection to work. It seemed to require a kernel module which wouldn’t compile for my machine and further research revealed little success or support for Comodo AV on more recent versions of Linux.

Sophos AV was the salvation. Easy to install, runs automatically as a daemon in the background and, thankfully, passed all the F5 tests with flying colours.

Summary

Given that I’ve gone through all the hassle of testing out various approaches to this, the above is all in all a fairly simple set of steps to keep the remote workers among you out of Windows territory despite the prevalence of Microsoft technologies in the corporate world. I’d of course be interested in other approaches Linux users have taken to such requirements because my own research in this space offered up very little in the way of useful material, in fact the closest I got was an article from f5 describing how to install the end point inspection client on your machine, but that is so straight forward that it really doesn’t bear mentioning. What I was really after was the material in this article and that, it would seem, for the time being at least, is nowhere but this page!

For a variety of reasons many shared web hosts provide only FTP accounts, not SSH shell based access. While I would never recommend such a host to a die hard Linux fan, I have occasionally had the requirement to work with such accounts for friends. Clearly I’m not about to break my workflow and use FTP commands and/or web based MySQL tooling, so how to proceed?

Firstly, bizarrely, many hosts despite not providing SSH access, *do* allow you to have remote MySQL access, so with a local mysql-client library installed and the correct rules in CPanel to permit one of my static IPs access, I can easily run commands on the remote database. I won’t include a tutorial because, if your CPanel has such an option and you’re an avid Linux user, you’ll know what to do.

Getting around FTP is slightly harder to do and there will be some caveats. The main limitation will be that nothing can replace direct shell access; you won’t for example be able to execute processes on the remote host. You will however be able to work with the file system as if you were logged in over SSH. The method we will use here is to mount the remote FTP filesystem to a directory on our local machine and then work with it locally. This means, for example, we can develop live in PhpStorm and have the changes reflected on the remote CPanel administered server – neat!

So, to get this working you need to install curlftpfs. On my debian based system with sudo, apt command is as follows

sudo apt-get install curlftpfs

Once installed you can then mount the file system using the following command – be sure to swap out your hostname, user, password etc.

curlftpfs '<username>:<password>@<hostname>' /home/<local-user>/ftp/

And that’s it! You can then navigate to the directory in question and work on files in there as if they were local to you. When you’re finished you can unmount as follows

umount /home/<local-user>/ftp

Finally a little known fact about many CPanel configurations – they support cron jobs! This means that if, as a one-off, you *do* need to execute something on a remote server to which you do not have shell access, you can drop the executable onto the box via the FTP mounted file system method above, apply the appropriate CHMOD and then schedule your command to run as a timed job in CPanel. If you direct the command output to a log file then you can even tail that log file on your own machine over the mount point to allow you to track progress of the script!

A strange thing happened the other day. I built a basic custom theme for WordPress, gave it a name, version and deployed it locally. Immediately my updates page was complaining that 1.0.0 was out of date and that I should install 2.0.1

Hovering over the link to the update gave me a clue as to what was going on. The *directory* name into which my custom plugin was installed is picked up by WordPress as the theme name slug and passed to the WordPress.org API to check for updates along with the version I specified in the theme files.

That means that even on an intranet, unless you block WordPress.org API calls, you mustn’t have any collisions in the theme names with the repository. This also means that if you come up with a completely novel and custom name for a theme that currently isn’t in the repository, the day a developer releases one with the same name and your version differs, your custom, private theme will be flagged as out of date.

I’m not suggesting that this behaviour is wrong on the part of WordPress, I’m not really sure they could do anything else, I just wanted to flag it up as something you may come across. If anyone has any API hooks that can be used in a theme functions.php to block checks then this may well be a solution – feel free to post a comment!

I upgraded the Akismet anti-spam plugin on my site earlier only to be greeted with a message stating “your akismet key is invalid”. Turns out that despite having my personal key since early 2006, I had to re-request the key on the Akismet site. I noticed when I did this that I was encouraged to pay a subscription fee of my choosing.

While I do completely understand the need to monetise services like this, I really didn’t like the underhand way in which I was forced onto that page. Plugin upgrades shouldn’t render a previously issued key invalid and certainly shouldn’t force you onto a site where payment is solicited to proceed (even if you can side-step this). As a plugin author, if I published a plugin into the WordPress repository that did this kind of thing I’d likely have my entry deactivated for violation of terms of service – smacks of double standards to me

At some point in the future I’ll be writing a more comprehensive article on linking external applications authentication to the phpBB user system, but in the meantime, if you just want to hash passwords or compare hashes then the following code is really useful

define('IN_PHPBB', true);
$phpbb_root_path = './';
$phpEx = substr(strrchr(__FILE__, '.'), 1);
include($phpbb_root_path . 'common.' . $phpEx);

$password = 'password';
$hash = phpbb_hash($password);

if (phpbb_check_hash($password, $hash)) {
echo '"Hash "'.$hash.'" matches password "'.$password.'"';
}

It allows you to run a separate php file which utilises phpBB functions to hash passwords; call it from a shell script, use it to login to servers etc.

Now as any developer who’s dabbled with WordPress knows, it’s easy to change the root directory location of WordPress so that directory structure wise different CMS systems can play nicely alongside one another.

What about, however, the situation where two CMS systems both require a root file of index.php? Well there you have a problem because if you change the name of the WordPress index file, which on the face of it seems easiest, you break the search feature (and possibly other things I’ve not found yet).

Fortunately I found a simple 3 step method which requires modifying only 1 line in 1 core file, which compared to other CMS systems, is not that many.

1. Firstly you’ll want to follow the instructions on the link at the start of the article to move your WordPress root away from the root of your site so that it can co-exist with your other app. Then, instead of creating a file named index.php in your website root, you create wordpress.php or another name of your choosing
2. Secondly, in the .htaccess file you created as part of the aforementioned guide, replace instances of index.php with wordpress.php or whatever name you chose
3. Now, for the final bit of magic, locate the following file wp-includes/class-wp-rewrite.php and replace
   

   public $index = 'index.php';

   with

   public $index = 'wordpress.php';

   taking care to use your alternative file name if it differs

That’s a wrap as they say! You should find that WordPress works fine, including the search feature, all the while leaving index.php free for use by another CMS. Do let me know in comments how you get along with this if you try it.

Oh and remember, if you upgrade WordPress, which will happen every now and again, do check to make sure your core file change gets put back – I hate to change core, but as index.php is hard-coded, it’s the only way.

A while ago I made a passing comment about replacing StartSSL using Let’s Encrypt and while it’s true you can use it in the way I described, it’s not as simple as the command would imply and there are a number of pitfalls – not least that if you side-step most of them by going a truly manual route, your efforts only last for 3 months – let’s encrypt certificates expire after only 3 months.

What this all boils down to is that in order to make proper use of this excellent free service you have to automate the process of obtaining and renewing certificates. Not just that though, because their python tooling (certbot) will do this in a general fashion for you, but to truly implement a hands off one size fits all solution. I articulated this as the following requirements.

• Tool must check for impending expiry and renew in time to avoid nag e-mails
• Support should be available for adding new certificate requests to the “pool”, not just to renew existing ones
• A fixed, permanent web server must not be required
• Servers running on non-standard ports must be supproted
• Servers not ordinarily accessible to the public must be supported
• Firewall must not be required to always be open to Let’s Encrypt servers
• Tool must support servers who’s control IP (SSH etc.) differs from that to which an SSL certificate is to be assigned (A record of SSL domain)

A evening of hacking around on a Raspberry Pi to get certbot running and some hasty coding in bash revealed a solution which essentially, does the following, in order, for each domain requiring a certificate.

1. Checks to see if the domain has a cert and if it’s expiring
2. Creates a remote directory from which files will be served as part of the renewal process
3. Inserts a temporary firewall rule to allow Lets’ Encrypt servers to validate the served files
4. Starts a temporary lightweight webserver to serve said files and runs it on a port that Let’s Encrypt supports (80)
5. Mounts this served directory locally on the certbot machine so that certbot can load files into it
6. Runs certbot to create/renew the certificate
7. Unmounts the temporary server directory
8. Stops the temporary webserver
9. Removes the temporary firewall rule
10. Cleans up temporary files
11. Load the certificate files onto the remote server over SSH
12. Bounces any services that use them so that they are picked up (e.g. Apache)

Before I share the script, a few words of warning and a few pointers

• Everything needs to run as root
• I mounted a NAS share of my certificate files so that they were stored and backed up centrally. Certbot expects to find everything in /etc/letsencrypt so that will need to be your mount point if you use the NAS option
• The script assumes that the server on which it is running has SSH keys setup on all hosts it needs to connect to such that passwordless root is possible.

If you don’t know how to do any of these things then you probably shouldn’t try using the script. It’s not that you won’t be capable or anything, rather that there are a lot of moving parts and basic Linux knowledge that would allow you to achieve these 3 points will go a long way in helping you to debug any issues with the script.

Finally then, the script; configured for two dummy domains, running on the same box, one serving from apache, the other a custom process.

#!/bin/bash
# Configuration section
email=your.email@address.com
certPath=/etc/letsencrypt/live/
remotePort=80 # Lets encrypt only supports 80 - ouch - we'll need to stop servers while doing this
domains=('one.domain.com' 'two.domain.com')
hosts=('1.2.3.5' '1.2.3.6')
sshHosts=('1.2.3.4' '1.2.3.4')
sslPathOnServer=('/etc/apache2/ssl/' '/etc/specialprocess/ssl/')
keyFileNameOnServer=('www.key' 'pub.key')
certFileNameOnServer=('www.crt' 'cert.crt')
chainFileNameOnServer=('www-chain.pem' 'chain.pem')
serverStopCommand=('/etc/init.d/apache2 stop' '/etc/init.d/specialprocess stop')
serverStartCommand=('/etc/init.d/apache2 start' '/etc/init.d/specialprocess start')

# Work is done here, no further edits!
i=0
for domain in ${domains[@]}; do
        # Ascertain if the certificate will expire in 3 weeks or less - stops lets encrypt nagging e-mails
        new=0
        if [ -d "$certPath$domain" ]
        then
                openssl x509 -in $certPath$domain/cert.pem -checkend $(( 86400 * 21 )) -noout
                result=$?
        else
                new=1
                result=1
        fi
        if [[ $result == 1 ]]
        then
                # Report the status
                if [[ $new == 1 ]]
                then
                        echo "Certificate for $domain [New]"
                        echo "Running certificate creation process..."
                else
                        echo "Ceritificate for $domain [Expiring]"
                        echo "Running renewal process..."
                fi
                # Start renewal process; create remote directory, iptables rule, start remote server
                echo -n "       Setting up iptables rules on remote server, stopping server process using certs & starting temporary micro server..."
                rule="INPUT 1 -p tcp -m tcp --dport $remotePort -d ${hosts[i]} -j ACCEPT"
                ssh root@${sshHosts[i]} << ENDSSH > /dev/null 2>&1
                eval ${serverStopCommand[i]}
                mkdir /tmp/$domain
                iptables -I $rule
                cd /tmp/$domain
                python -m SimpleHTTPServer $remotePort > /dev/null 2>&1 &
ENDSSH
                echo " Done"

                # Mount remote directory locally over SSHFS
                echo -n "       Creating mount to directory served by temporary micro server..."
                if [ -d /tmp/certbot ]
                then
                        rm -rf /tmp/certbot
                fi
                mkdir /tmp/certbot
                sshfs ${sshHosts[i]}:/tmp/$domain /tmp/certbot
                echo " Done"

                # Call letsencrypt to renew/create
                echo -n "       Call letsencrypt to renew the certificate in our store..."
                letsencrypt certonly --webroot -n -w /tmp/certbot -m $email -d $domain > /dev/null 2>&1
                echo " Done"

                # Unmount remote SSHFS directory
                echo -n "       Unmounting micro server directory and cleaning mount point..."
                umount /tmp/certbot
                rm -rf /tmp/certbot
                echo " Done"

                # SCP certificate/chain/key files to remote host
                echo -n "       Copying new certificate files to the server..."
                scp $certPath$domain/cert.pem ${sshHosts[i]}:${sslPathOnServer[i]}${certFileNameOnServer[i]} > /dev/null 2>&1
                scp $certPath$domain/privkey.pem ${sshHosts[i]}:${sslPathOnServer[i]}${keyFileNameOnServer[i]} > /dev/null 2>&1
                scp $certPath$domain/chain.pem ${sshHosts[i]}:${sslPathOnServer[i]}${chainFileNameOnServer[i]} > /dev/null 2>&1
                echo " Done"

                # Cleanup remote host; stop temp server, reload default iptables, cleanup temp directory, restart server process
                echo -n "       Stop micro server, clean up iptables rule & start server process using certs... "
                ssh ${sshHosts[i]} << ENDSSH > /dev/null 2>&1
                kill \`ps -ef | grep SimpleHTTPServer | grep -v grep | awk '{ print \$2; }'\`
                iptables -D INPUT 1
                rm -rf /tmp/$domain
                eval ${serverStartCommand[i]}
ENDSSH
                echo " Done"

                # Confirm completion
                if [[ $new == 1 ]]
                then
                        echo "Certificate for $domain [Created]"
                        echo "Creation process complete"
                else
                        echo "Renewal process complete"
                        echo "Certificate for $domain [Renewed]"
                fi
        else
                # Certificate needs no renewal, indicate as such
                echo "Certificate for $domain [OK]"
        fi
        i=$i+1
done

You’ll need to modify the variables/arrays at the start to get it working, some are obvious, but I’ll explain them anyway.

• email : This is used to create, recover and access your account. Once created, the private key for accessing your account will be stored in the let’s encrypt home directory (usully /etc/letsencrypt)
• certPath : The path to the /live directory in your let’s encrypt home directory, usually /etc/letsencrypt/live
• remotePort : Leave this at 80; it’s just here to help setup iptables rules – it cannot be changed in let’s encrypt config
• domains : An array of domains for which you want certificates
• hosts : An array of IP addresses corresponding to the aforementioned certificates – keep the ordering the same!
• sshHosts : An array of IP addresses used for administering each of the aforementioned domains; for example you may have several web servers/domains all being served from the same physical host – this would then be an array of identical IPs, corresponding in array size with the number of domains
• sslPathOnServer : What is the file system path to each domain’s certificates on the host server
• keyFileNameOnServer : Within that directory, what is the key file name
• certFileNameOnServer : Within that directory, what is the certificate file name
• chainFileNameOnServer : Within that directory, what is the chain file name
• serverStopCommand : For each domain, what command stops the server process the domain is used for
• serverStartCommand : Likewise, what is the command to start the server process again

That’s it! Best of luck if you choose to go this way and do let me know if the script is useful to you.

I recently did a apt-get dist-upgrade on my Raspberry Pi running Raspbian 8 and when I rebooted the device appeared to drop clean off my network. I was away from home at the time so I decided to fix it when I was next on the premises – it wasn’t a hugely important device to have running 24/7.

When I looked at the device in person I realised that it was in fact connected to the network, but with a different IP address to that it had held before. Having MAC address based IP allocation, this seemed rather strange. Looking at the MAC address in ifconfig revealed the problem – it had changed! Thinking this to just be a fluke, I rebooted. Now, not only was the MAC still different to that which it should have been, it had changed a third time!

Investigating what had happened during the upgrade revealed that both the bootloader and the kernel had both been upgraded, but for whatever reason, the new kernel wasn’t being loaded. Modifying the /boot/config.txt as follows along with a reboot fixed this discrepancy and lo and behold the MAC returned to it’s former value and the device picked up the IP address it was supposed to have over DHCP

From

[pi1]
kernel=vmlinuz-4.4.0-1-rpi
initramfs initrd.img-4.4.0-1-rpi followkernel
# to enable DeviceTree, comment out the next line
device_tree=

To

[pi1]
kernel=vmlinuz-4.9.0-2-rpi
initramfs initrd.img-4.9.0-2-rpi followkernel
# to enable DeviceTree, comment out the next line
device_tree=

It’s worth pointing out that you may have a similar problem with a similar cause but slightly different kernel versions to me. If this is the case, or to check if it is, verify the old/new versions in /boot as follows

ls -lha /boot | grep initrd.*rpi

Which will reveal your old/new versions

-rwxr-xr-x 1 root root 5.7M Jul 3 18:26 initrd.img-4.4.0-1-rpi
-rwxr-xr-x 1 root root 13M Jul 3 18:46 initrd.img-4.9.0-2-rpi

You should then modify /boot/config.txt from the old version to the new version as per my above example.

After a recent holiday I wanted to download the photos from my iPhone – something I’ve long been able to do in Linux. Upon following my well trodden process, I was greeted with an unfamiliar error message

$ ifuse /media/kieran/iphone
Failed to connect to lockdownd service on the device.
Try again. If it still fails try rebooting your device.

Some reading around the subject revealed that encryption needed to be disabled on the libimobiledevice module that is used under Linux to pair with the iPhone. Rather than go to the effort of modifying the source myself, some helpful chap has already done this and published the code and usage guide to GIT. Hope this pointer helps someone who is stuck trying to access their phone.

A small service I created for personal use had its SSL certificate expire a few weeks ago. I replaced it using my go-to free certificate provider, StartSSL. Unfortunately, accessing this service from my iPhone still didn’t work afterwards, or rather it did, but the certificate still wasn’t trusted. I was forced to ignore this issue at the time due to other pressing matters and, as the service was just used by me, on my device, I simply set the app to ignore the issue until I had time to diagnose the problem properly.

Today I replaced my e-mail signing certificate, also from StartSSL. This time I knew something was wrong; adding the certificate to Thunderbird and sending a test e-mail to be retrieved by my iPhone, the certificate again wasn’t trusted.

Turns out that silently, unbeknownst to me and I’m sure many others, the following chain of events has occurred

1. StartCom which runs StartSSL were taken over by WoSign
2. Due to past issues with WoSign regarding the erroneous issuing of certificates for a domain that they had no authority to issue for, they had their root certificate rights revoked by Apple, Mozilla, Google and others
3. Since the take over of StartSSL, the aforementioned device/software companies have also ceased to trust the root certificates of StartCom.

This has resulted in my having to spring into action. The silent take-over of a previously trusted organisation by a dubious one located in a political jurisdiction known to be questionable with respect to web security is worrying enough, but with the added pain of being unable to send signed e-mail and issue new certs for my soon to expire domains required to be addressed immediately.

I’ve found that comodo, a trusted certficate authority, will issue free e-mail signing certs so I’ve jumped over to that immediately for e-mail and that is running nicely.

In addition there is “LetsEncrypt”, which, once installed, allows you to generate trusted SSL certificates for your domains using the following command

letsencrypt certonly --manual -d my.domain.com

When running the above it’s important to remember that validation you have control over the domain for which the certificate will be issued requires you to

• Be running a web server on port 80 on the domain
• Said port 80 server to be accessible publicly through your firewall
• For you to place a file to be served on the web root of this server

You can always stop apache (or whatever your web server is) and run up a simple stand-alone python server to do the job, but you won’t be able to get away without changing your firewall rules.

This is a departure from the way I’m used to doing things which used the administrative e-mail address registered to the domain and code sent to this for validating I owned the domain. This was nicer as it meant I didn’t have to play with my config all that much (some servers I run use non-standard ports and don’t have port 80 open by default for example).

Anyhow, from my reading of the documentation about LetsEncrypt, it seems that all major browsers and Apple iOS are trusting certificates signed this way. I’ll update this post if that turns out not to be the case, but I’m optimistic.

Hopefully this post will help to raise awareness and also assist some folk out of a bit of a pickle with their security arrangements.