Security

In many companies, appplications quickly become a web of interconnected systems with dependencies upon each other and testing changes to a single application may be hard, as the behaviour of the application may depend on interaction with other interconnnected applications.

Ideally it would be nice to have a test complete environment with (dedicated) test versions of any other application impacting the application being tested - and have a coherent and applicable test-data set to use (but let’s leave test data for another post).

I have for many years paid to have a fixed IP number at home. The main reason was to allow me to access servers and have the remote access restricted to the home IP number. This was just one of many layers of the security of the server and the SSH setup, but no more.

I’ve been playing with (Tailscale)[https://tailscale.com/] which essentially provide an overlay network and allows you to have a secure private network across the public internet. Tailscale has a free plan perfectly suitable for my uses and clients for just about any machine, so getting all machines attached to a private network through Tailscale is surprising easy.

If you’re jumping around on servers and need to figure out what the IPnumber(s) of the server are, here’s a little bash line which usually works (tough with a few catches):

ifconfig eth0 | grep inet | awk '{ print $2 }'

This command assume the eth0 is the public WAN interface in the server. If there are more network cards this may not be correct - or the only interface for the net.

Got access to a wifi network, but forgot the password? No a problem. At least not if you have a windows, Mac or Linux machine with access. All these OSes can basically without restrictions show you the wifi password in clear text.

Windows

Once you have access to the wifi network. Open the commandline and enter the following command replacing “SSID” with the actual name of the wifi network you want to retrive the password to.

netsh wlan show profile name=SSID key=clear

Get your company implementing DMARC now…

During the past 5-6 years email industry efforts have been pushing the DMARC standard along. It provides the best widely supported and seemingly efficient way to - as a domain-owner - protect the domain from misuse and abuse in terms of spam and phishing attacks.

As sending email has often been a wild-west, and knowing who is a valid sender of email may prove a challenge for many companies - and as most IT developers does seem to care too much about the finer details of email (and production just as bad email headers as HTML markup :-) ), implementing DMARC protection on your domain may actually be a challenge.

When using Viscocity to connect to a corporate network or any other openVPN server, you’re probably using certificates with a reasonable lifetime, but sometimes the certificate expire and needs be updated. Replacing the certificate files through the Viscocity interface is quite easy - just edit the connection and replace the certificate files in the appropriate tab.

There is however another little trick, which may need to be applied before the new certificates work. Viscocity offers to save the certificate password in the Keychain and I choose to use this feature, which caused a bit of trouble when updating the certificate. While it ought to - Viscocity does not - clear the password, when the certificate is changed, so to get prompted you need to go into the Keychain access tool and delete the stored password.

One of the great features of Wordpress is the wide variety of plugins available. They often enable a lot of interesting functionality and integrations to other services not native to Wordpress itself. Most of these plugins are developed by individuals or small teams independent of the core community - and often not with a keen interest in security, but an exclusive focus on “making stuff work”.

I’ve been using the Wordpress “Google AdSense Dashboard” for awhile, and after the recent host of password leaks, I’ve been changing and upgrading password all around. This change lead to expose what I would call a critical password exposure in the plugin and so far caused me to remove the plugin everywhere I’ve installed it.

While surfing the net, you often come across web agencies how promote SSL-certificates (or TLS security) on their products - or their ability to create “secure web applications” with SSL. Most users know HTTPS/SSL/TLS as the little lock, that promises “security” when visiting a page - but what kind of security it actually provides is rarely explained - and far worse often misunderstood.

The while SSL is the popular name (and as it was once known) and HTTPS usually is the way users sees it (as part of a URL in a browser) - the correct name is TLS a short for Transport Layer Security.

I’m still enjoying the fresh new Ubunutu 9.04, and one of the nice new features is a firewall – which Canonical calls “Uncomplicated Firewall”. I’m usually not hooked on firewalls, but just for the fun of it I enabled the firewall on my laptop and it seems to work quite well. The firewall doesn’t seem to have any noticeable impact on system performance and as the laptop from time to time visits open wifi’s, it’s probably a good idea to have protection from other users on open networks.

It’s often the case that security is an inconvenience and gets in the way of usability and ease of use. There are exceptions though and for a number of weeks I’ve been playing with the Yubikey (thanks to Schack) from Yubico.

It’s a small device, which plugs into a USB port, and to the computer acts as a keyboard. It has some advanced security build-in with the ability to generate one-time verifiable passwords, but is incredible easy to use – plug it into the USB port and press the single button when you need to sign in to services supporting the Yubikey.