Doublehops

Last month I was one of 15,000 people that attended the Defcon computer security convention in Las Vegas. It was a fantastic four day event with presenters talking about their findings and projects in regards to all things security.

Upon paying the $200 entry fee we were given our badge required for entry. This year’s badge was electronic and a puzzle in a way. Through onboard lights and light sensor the badges would communicate with each other as they past by. Also via a USB port we were encouraged to program some hacks so that they behaved differently.

Defcon 2012 Badge

One of the most interesting events in Capture The Flag where teams are set against each other to hack into their opponents servers and capture so called flags. Each team would harden their own servers before beginning to attack others. From what I could gather they do this non-stop throughout the event and the team who has gathered the most flags is deemed the winner.

My highlights were sitting in on talks by Kevin Mitnick on social engineering and Kevin Poulsen discussing the exploits he used to get up to in his past. Having read books by both presenters I was keen to see what they had to say.

I would love to attend again next year. Anyone feel like sponsoring my trip?

For the last three months I have been working on different websites that I inherited that rely heavily on Redis. Redis is another no-sql database that uses key/value pairs to store data but does not give you the flexibility to write queries like you’re used to with relational databases like MySQL and Postgres.

Interestingly, these sites also use MySQL. I never had a chance to use or learn about No-SQL databases beforehand but the idea of using two types of databases for one application sounded like a convoluted and unnecessary solution. However, the more I use Redis (especially in these applications) the more I love it.

Redis is used in these applications for caching. When a request it made, rather than PHP sending queries to MySQL, it requests the data directly from Redis, which is pulled straight from the RAM. This results is a much faster response time and requires less resources from the server.

As there are already some good tutorials on what Redis is and how to use it, I will show you some great tricks I found through my travels that I did not see in the general documentation. Start the Redis client (redis-cli) and try the following two tricks:

List All Keys In The Database:

keys *

Show Variable Type:

type <variable-name>

Monitor Queries:
Monitor the queries being sent to Redis by using telnet to login to redis on the port number it’s running (default 6379) and type monitor. This is very helpful if the queries are being sent from an application and you need to debug exactly what’s the query is.

Running Multiple Instances Of Redis:
As I am running multiple applications that require Redis, I needed to learn how to run multiple versions of Redis. This is because you don’t define separate databases like you would with MySQL for example. There is no logins and no way to clearly separate data between applications. An excellent description on how to run multiple version of Redis can be found at chrislaskey.com.

Start Learning:
To get a better understanding of Redis I recommend using the online practical guide found at try.redis-db.com. This guide explains what different types of variables are available and how to access them.

Conclusion:
Redis has shown me what’s available in no-sql databases and that relational databases may not always be the answer. I can see that as I use Redis more in my own projects I will find that it’s useful for other purposes.  One possibility is the storing of variables that I may have previously put into sessions.

I have been working with Linux and web development for over seven years and in this time I have used several hosting companies as well as set-up some development servers at home in order to host and develop my websites. I had recently decided to take the plunge into getting my own virtual server account so I would have a live environment where I would have full control.

I chose Slicehost as my provider as I have used them in the past at work and found them to be reliable and the control panel and service to be exceptional. As with this type of virtual host you are given a completely new install with bare services running. This means that as a web server you need to manually install everything from Apache, MySQL and PHP manually. Also you will probably need to install a mail service.

The tough part for me was installing and configuring the mail. This is not something I do with my dev boxes at home. This was a bigger learning curve than I imagined but very rewarding. The greatest part with virtual hosts is that if you completely screw up, you can easily choose to rebuild your slice and start again from scratch.

Also through the slice manager you can easily configure DNS for any domains and subdomains hosted on the server.

Anyway, some of the best things I have learnt from the experience are:

• Setting up a mail server with encryption and smtp authentication for imap accounts using mysql.
• Setting up the firewall using iptables.
• Learning how to login over ssh without passwords.
• Setting up a Subversion server with SSL encryption.

It has been very satisfying to step away from the traditional hosting companies and have full control over my hosting. I recommend anyone else with Linux experience who is thinking of getting a virtual host with full root access to give it a go. There are some good ones about and the experience gained are better than I would have hoped.