Monday, 15 June 2015

Keeping your portable data "secure"

I recently attended the Info Security Europe conference held at Olympia, London. It was a huge three-day event (although I only went on the first day) with a number of high profile security, anti-virus and other related companies trade stands.

Not only that, but there were also a number of live hacking events, seminars, presentations of all-sorts (mostly sales pitches) and a few off-beat companies who provide specialist services.

I wasn't there for the sales pitches. Not interested in monitoring software. Not wanting to purchase hardware. I was looking for information and useful tools.

OK, I tell a lie. Although I wasn't looking to buy hardware, I did come across one company that was selling something a little unusual and very interesting. The company in question sold USB and SSD drives that were encrypted and hardware password protected.

The company in question was iStorage,

and the product which caught my eye was the datasur USB drive.

Now for years I've used a multi-boot USB drive for my most important tools. I used YUMI to handle the drive installation where I can boot the disk into multiple platforms. But this was on an unprotected drive, where if people could have got hold of it they could have used it as well. I had to use a TrueCrypt partition to protect some of the data on there, but it was always a pain loading the partition after the boot. So now there was the chance of having a secure drive right off the bat. So I bought one right there and then at the show.

A couple of days later and DHL dropped off a small packet with the enclosed drive. The device itself is very easy to use. It comes pre-formatted with a copy of the manual sitting in the root directory and a little data card which gives the default PIN and information about how to go about changing it. Needless to say, I changed the PIN. This was now my secure drive of choice.

So I fired up YUMI, got together a collection of my most useful .ISO images (which I always have handy anyway) and started getting things running. It was at that point my elation died as did, it seems, my drive. After running YUMI and installing my copy of Kaspersky Rescue Disk (always my first install of any new drive), the drive promptly detached and became unusable. Looking in the device manager it simply showed up as an unknown USB device. According to the instructions, if you get the access code wrongly ten times in a row then the drive should reset. So that's what I did. But to no joy, the device was still unusable.

So I contacted the iStorage support team to ask for help. They immediately dispatched a brand new drive without question. The failed disk I sent back to their Technical Support department. It was later determined that the failure was due to a faulty controller. Not due to an incompatibility with the YUMI multiboot configuration which was my first thought.

The moral of this story is one of user satisfaction. The iStorage Support Deptartment spared no expense to ensure that I, as a customer, was satisfied which their product. As in all businesses, if you don't have happy customers then your business model is wrong.

My only criticism with this device is an odd one. As I mentioned before if you enter the wrong code, 10 times in a row, then the drive is wiped and scrambled. So anybody who physically gets hold of your drive can blank it in just a few seconds and wipe all your valuable data. So there is a difference between accessible security and deletion security. It's harder to wipe a normal drive since you have to access it then wipe it via the computer.

But it all depends on what sort of data you keep on the drive. You did remember to keep secure backups of your important stuff didn't you?

Wednesday, 18 March 2015

Keeping Terry Pratchett alive

In Terry Pratchett's novel "Going Postal", anybody who dies in the service of the Clacks is kept alive by their name being transmitted over the wires. "A man is not dead while his name is still spoken," as one character puts it.

There has been a discussion on Reddit to immortalise Terry Pratchett's name in a similar manner. By adding his name to the X-Headers that are sent with every web request.

You can add this entry by simply selecting your website in the Web Configurations section of Domino and creating a Rule, like so:

My small contribution to a great man I once had the honour of meeting. I'll treasure my signed copy of the Colour of Magic.

Monday, 9 March 2015

DropBox and Server logs

If, like me, you run a few servers then your log files are vital to determining the health of your systems. The logs generated may be huge. Some are daily. Some are weekly. Some are only generated when a server encounters a problem and resets. Some are boring. Some are so damn useful in tracking down that annoying bug.

But all of them should be kept and analysed.

I've lost track of the number of times I've seen websites under attack. Some of these attacks are insidious in the way they are undertaken. The attacks themselves are spread out over time so that it's almost to distinguish the attacks from regular usage. Other attacks simply bombard your server with a high frequency that sends your server into fits of 404's and 500's.

But one thing you really need is to get those logs into a place where they can be assessed and archived. Now I have servers all over the place. But the servers which generate those logs are not accessible except via remote control which is time consuming and laborious to setup. So how can I get those logs into a central location?

Cue DropBox.

If you can install DropBox on the server then setting your log files to be dropped into a folder that is synchronised will allow those files to be sent to you whenever they change. It's simple and effective. But if you have many servers then this can become a bit of a pain. Having the same account might work for all your servers, but generally log files can grow to large sizes. DropBox can cope with this by simply ignoring the files that sent it over the limit. On your workstation you can then move the logs out into local storage clearing up space so that DB can then send down the remaining logs. DB is good like that.

But there is a better technique. One which can give you better overall control, but it does take a lot of organisation in the first place.

You will need an email address and account for all servers, plus a control (unless you wish to use your personal account). First register a control user which will act as your central "hub" for receiving your log files. Then send "invites" to all of the servers which you then wish to manage the logs of. Install DB on all of your servers using the invited emails. DB will give you a little bonus space for your servers, as well as a large bonus space for your control account. Once you have your accounts installed on your servers, you then need to create a shared folder for your log files. This is then shared with your control account.

Using this method gives you multiple benefits. Firstly, each server only has their own logs. you're not distributing the logs across all servers which is better for security. Secondly your control account now has an increased capacity for handling the logs. Always useful considering how many you will probably need to manage. Thirdly you have a better indication if any issues arise. A simple script can see which servers haven't yet communicated back their logs and you can then go and check out those servers for issues. That is unless you haven't been smart enough to set up other alerts for your systems in the first place.