Archive for Computers & WWW

Export Public Key From pkcs12 Container

Everytime I renew my S/MIME certificate I always seem to wind having to consult the OpenSSL man pages to ascertain the approrpiate command to use in order to extract the certificate from the PKCS12 file I get from my certificate authority so I can share said certificate on my contact page. As I’m sure I’m not the only one who winds up having to look this up, I’m sharing it here.

openssl pkcs12 -in container.p12 -clcerts -nokeys -out public.pem

If you then investigate the contents of the PEM file inside a text editor you’ll find your certificate between the BEGIN and END lines – you should share this content on your website or directly with contacts so that your signed e-mails can be verified as to their origin and also so that contacts can encrypt mail such that it can only be read by you if required.

Comments off    

Handling the Heartbleed Bug

So when news of the Heartbleed Bug hit the tech news sites and security bulletins I decided to read up on it when I got home from work and go from there. While it’s true that some news sites aimed at the general public have gone rather over the top about this and in many cases got their facts and recommendations plain wrong, my evening reading was not that enjoyable – this is indeed a very serious bug and is likely to affect everyone in some way shape or form. Note that I said affect, and not compromise – this is important – there was and still is no evidence that the bug was being exploited in the wild.

For those with a technical inclination, the register has done a nice little round up of how the bug works. The non technical among you may find this heartbleed cartoon illustration over on XKCD more useful.

Anyway, I thought I’d share with you the steps I have taken and will be taking going forward to help mitigate the effects of the bug. I’ve laid out the steps in order, note that I’ve focused on external services first – this was deliberate – no sense in using external services to help me fix my own infrastructure if they were not patched yet.

External Infrastructure

  • Verified with my hosting company that their servers were not affected. Xilo confirmed to all customers that their OpenSSL version was prior to the appearance of the bug. This ensured all keys stored in their infrastructure and used by me are secure
  • Ensured that my cloud based password management system was unaffected. LastPass were very open and detailed with their customers in explaining that despite their servers having been affected and subsequently patched and their certificates re-issued, a combination of passwords never being sent to their systems without an additional layer of encryption to which they never see the key and Perfect Forward Secrecy, customer data was and remains secure.
  • Verified that my certificate provider’s online portal is currently patched and protected. StartSSL have confirmed that their infrastructure was never vulnerable to the attack.

Own Infrastructure

  • Patched all servers I administer that were vulnerable – check yours here

    apt-get update
    apt-get upgrade

  • Re-generated all SSH host keys on vulnerable hosts (remember to leave the pass phrase blank)

    ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
    ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

  • Revoked certificates that were in use on previously vulnerable hosts. Some providers may charge for this but you’re not fully secure without it!
  • Re-issued certificates that had been revoked using new keys. Generate these and CSR as follows

    openssl genrsa -out server.key 4096
    openssl req -new -key server.key -out server.csr

  • Restarted all services using OpenSSL. In many cases this will be done by the package manager during the upgrade process but if you’ve changed keys etc. a restart will be needed to pick this up

    /etc/init.d/ssh restart
    /etc/init.d/apache2 restart

Passwords

  • Given that changing a password prior to a site admin both patching the server and revoking/re-issuing their certificate is a pointless exercise, I plan on relying on a combination of the LastPass checker and conversations with web masters directly about if I should change passwords or not. I’m expecting a large number to need changing but hopefully it can be done at a relaxed pace over the next few weeks as and when news becomes available regarding the vulnerability or otherwise of a site.

Finance

  • Confirmed, via the LastPass checker, that PayPal have never been vulnerable due to the software they use for SSL
  • While it’s possible that credit card numbers, bank details and indeed other personal details may have been leaked via the bug, I deemed that replacing bank cards etc. was overkill. After all most banks offer fraud cover and my subscription to credit report monitoring includes tools to help manage any increased risk of identity theft. In any case, many personal details sent in this way are not easily changed, in fact only a credit card number can really be replaced – bank details, national insurance number, address etc. are all set in stone.

Hopefully this overview is helpful to those who are confused!

Comments (2)    

Cannot update WordPress post

I came across an old post on my blog the other day that was getting a lot of hits. When I viewed the page I decided that the code snippet in the article could do with an increase in text size to make it more readable.

I went into the admin panel and added an in-line style attribute to the code tag in question. When I saved the page WordPress reported that the post had been updated, however the text in the editor screen reverted back to what it had been prior to my change. I tried numerous times to save and tried different browsers but try as I might, the change just wouldn’t “stick”.

I usually consider myself pretty adept at solving WordPress related issues but this one was stumping me so I did what all developers do when they are in a tight spot and I googled it. Most posts turned up were completely unrelated, but one article suggested that the issue may be symptomatic of a corrupted table.

A quick command as the MySQL root user had my answer and effected the fix into the bargain

[kieran@www:~/public_html]$ mysqlcheck --check --databases wordpress --tables wp_posts -u root -p
Enter password:
wordpress.wp_posts
warning : Table is marked as crashed
error : Key in wrong position at page 132096
error : Corrupt

I re-ran the same command to make sure it had effected a fix (it isn’t clear from the output)

[kieran@www:~/public_html]$ mysqlcheck --check --databases wordpress --tables wp_posts -u root -p
Enter password:
wordpress.wp_posts OK

Now updating the offending post works first time without issue. I suspect, although can’t be sure, that the corruption occurred during a recent upgrade of the server when not all the services, MySQL included, got shut down gracefully.

Comments (1)    

SecurityException in Application

When carrying out a recent upgrade of suPHP I encountered the following error in my apache error logs and PHP pages were not being served.

SecurityException in Application.cpp:511: Unknown Interpreter: php

Turns out the fix is a simple one; the syntax of the config file has change between versions and it’s simple a case of replacing the following lines:

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

With the following (note the addition of double quotes)

[handlers]
;Handler for php-scripts
x-httpd-php="php:/usr/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"

A quick bounce of apache and you should be back and kicking

Comments off    

Removing kernel from OpenVZ Container

When I recently upgraded an OpenVZ container in-situ over SSH, I had a few issues with the upgrade path. One of these was that the upgrade process called for the installation of a new kernel, however a container doesn’t need one and in my case couldn’t handle installing one either and thus caused the upgrade process to error out.

The fix was to force remove the kernel, both from the dpkg directory structure (in this case I copied the files to /tmp/ just in case) and using dpkg it’s self. The following commands as root:

mv /var/lib/dpkg/info/linux-image-3.2.0-58-generic.* /tmp/
dpkg --remove --force-remove-reinstreq linux-image-3.2.0-58-generic

Resuming the dist-upgrade after this process was a success

Comments off    

Easily Rotating Images

When grabbing photos from my iPhone I often find that it has a funny idea of where “up” actually is and while the EXIF data always allows you to correct the problem I’d rather my image was simply the correct way up to start with and an EXIF rotate tag of 0 degrees rather than upside down with an EXIF rotate tag of 180 degrees!

Luckily I discovered a little utility that can be plugged in to the nautilus file/folder browser on the gnome desktop which lets you simply Ctrl-click the errant photos and then right click and hit rotate, later entering the amount you wish to compensate the images by and away it goes and batch rotates the images for you.

To install on Ubuntu (or any other Debian based system) just run the following

sudo apt-get install nautilus-image-converter

Enjoy your properly orientated photos!

Comments (2)    

Hide SQLPlus Password String

Google is somewhat sketchy on what you have to do if you wish to hide the password string passed to SQLPlus on the command line from ps aux to enhance the security of automated processes on servers that may be accessible in part to others.

The answer actually turns out to be quite simple but it is best explained with a snippet of code, the below to be placed in a BASH script.

sqlplus -L /nolog <<EOF >> test.log
CONN user/password@tnsname
@test.sql
EOF

To explain the components then.

  • -L tells SQLPlus to only attempt a login once. This means that if access is denied, the account you’re trying to access won’t get locked after 3 attempts.
  • /nolog on the command line forces a prompt without a connection to a server. This allows you to specify a connection string as part of your script instead of on the command line which would then be visible to ps aux.
  • <<EOF indicates that the input to SQLPlus will be a stream of lines, to be read until an EOF is sent on a line.
  • >> test.log logs the output of the activities of SQLPlus to a named file, in this case test.log
  • CONN user/password@tnsname passes your credentials to SQLPlus and causes it to establish a connection with the server sitting behind the TNS name. Being passed this way the credentials will appear neither on ps aux or in test.log
  • @test.sql tells SQLPlus that it should read in and execute the file test.sql
  • EOF terminates the feed in of lines and causes everything fed in thus far to be executed

I hope this ends up saving some head scratching

Comments off    

Kworker High CPU

After a recent kernel upgrade on my home server I noticed that Kworker was hogging most of the CPU after boot and wasn’t dying down over time. Research online lead me to believe this was due to an ACPI interrupt storm creating a high load. I tested a fix for this by adding the following line to root crontab

@reboot echo "disable" > /sys/firmware/acpi/interrupts/gpe00

This essentially serves to switch off ACPI and upon reboot I found that CPU usage had indeed returned to normal. As setting ACPI to off has no impact on my home server and what it is used for I decided to leave this tweak in place and to check to see if it was still required when future kernel upgrades come around – this has been a widely reported bug on Ubuntu launchpad.

Comments off    

Removing Plymouth

While recently upgrading my headess Ubuntu home server I came across an issue whereby boot would hang due to some issue with plymouth, the application providing the graphical splash screen shown when Ubuntu boots. As this server is headless I decided that rather than seek to resolve the issues I’d simply remove plymouth, after all it isn’t any use on a headless system to show a splash screen on boot!

Plymouth is unfortunately a dependency in apt for two important packages, cryptsetup and mountall and as such cannot be removed using the usual apt-get remove method. As plymouth is in fact not really required by these components, we can replace it with a dummy package that will keep apt happy and allow us to boot up sans-plymouth.

Firstly configure a dummy package

vi plymouth

Enter in the following details

Section: misc
Priority: optional
Standards-Version: 3.9.2

Package: plymouth-dummy
Version: 1.0
Provides: plymouth
Architecture: all
Description: Dummy plymouth package to allow proper plymouth removal

Now build your new package

equivs-build plymouth

If you get an error running this command saying it doesn’t exist, install it using apt as follows, then re-run

apt-get install equivs

Once you have your dummy package, we can now force remove plymouth and replace it with it’s dummy. To do this without affecting any if it’s dependencies, we do this using dpkg

dpkg -r --force-depends plymouth

Then we replace what we removed with the dummy package as follows

dpkg -i plymouth-dummy_1.0_all.deb

We can now safely reboot the server knowing that plymouth will not be available at boot but all other components will be. For me this fixed an annoying partial boot problem, for you it may just mean the removal of a component you really don’t need in headless mode. Either way, I hope this proves useful.

Comments off    

Verify Email

I had cause today to verify if a number of e-mail addresses really existed and stumbled across this easy to use web based tool, verify email. It’s handy because it also provides visual feedback of the interaction with the mail server on the domain which saves you having to fire up a telnet session.

Comments (4)    

« Previous entries