Setting up SPF records for Google Apps and Amazon SES

Posted on April 21, 2014 | no comments

The Sender Policy Framework (SPF) is an attempt to mitigate certain types of spam – specifically spam where the sender masquerades as a different sender. Technically, you can put whatever you want in the From: header of an email message, so you can pretend to be sending emails from simply by putting something like From: [email protected] in your email’s headers.

Email relay servers prevent this by looking up the sender’s domain’s SPF record (defined in DNS records). The SPF record tells the mail server “here are some originating IP addresses that are legit, if a message arrives pretending to be from this domain, make sure the originating IP address is on this list”.

Using GMail and SES?

If you happen to be sending emails through Google Apps and Amazon SES (e.g. automated system emails via SES and “real” person-to-person emails via GMail), you need to ensure that your SPF record is set up to allow for both domains.

So here’s how: put this in your DNS system’s TXT and SPF record (why both?):

"v=spf1 -all"

Note: the -all denotes that mail servers should not trust emails from anywhere else but the defined domains. If you’re unsure or believe that you might need to send mail via other domains as well, use ~all (soft fail).


Tags: , , , ,

What is Heartbleed and why do I care?

Posted on April 9, 2014 | no comments


Heartbleed is a bug in the OpenSSL library that was publicly disclosed on April 7th, 2014 by an internet security firm called Codenomicon. With OpenSSL being the defacto SSL library in both the Apache and nginx webservers, that potentially exposes about two thirds of the internet. If we exclude the websites that don’t use SSL at all, we are left with a nice round number: half a million.

Half a million websites exposed to a security hole of this magnitude is completely unheard of in modern history. The mad scramble to get this hole plugged has been ongoing since the disclosure and has involved some major players with Amazon AWS, GitHub, Google and many more putting out announcements about their remediation efforts in the last 48 hours. Here in Canada, the CRA (Canada Revenue Agency) actually shut down all its online filing systems until they could get it sorted out. Maybe a little late, but at least they’re on top of it. Not bad for a monolithic federal department.

The cloud hosting company CloudFlare apparently got wind of this bug about a week before anyone else which begs the question – why did they get told before anyone else? Why didn’t they or the researchers notify any of the major linux distributions? NDAs? We might never know, but either way this does not sound like a “responsible disclosure” to me. When security bugs like this are actually disclosed responsibly, poor sysadmins aren’t up at 3am building custom RPMs while frantically revoking as many SSL certs as they possibly can.

How did this happen?

The cause of the Heartbleed bug (a.k.a CVE-2014-0160) was probably one of the rookiest mistakes you can make as a C programmer. Anyone who’s ever written C code before will know the pain caused by not doing bounds checks when performing any kind of memory access. That’s exactly what happened here.

What’s the damage?

In my opinion, the really sad part about all of this is that this bug has been floating around for over 2 years. Anyone who was savvy enough, and wanted to attack someone using this exploit enough will already have done so. The effects of this security breach are going to be felt for years as slow hosting companies neglect to upgrade in time, SSL certificate keys become compromised, people’s account details get stolen and so on and so on.

What do we sysadmins do about it?

The key things for sysadmins to do right now is upgrade their versions of libssl and openssl ASAP. Decent system administrators will get this done NOW (maybe sooner – get a time machine since we’re 2 days in) using official channels or recompiling them yourself with the OPENSSL_NO_HEARTBEATS flag enabled. Good system administrators will also revoke their SSL certificates and issue new ones. Great sysadmins will also revoke/replace their SSL certificates with brand new ones generated using brand new shiny private keys since the old ones should be considered compromised as well.

Wait, why do I care again?

Imagine a smart (but evil) attacker setting up a standard Man-in-the-middle attack and pretending to be your bank’s online web portal. Normally this can’t be done because your computer trusts this web portal because it identifies itself as legitimately being your bank using SSL (or TLS more specifically). The attacker can’t impersonate your bank because he doesn’t have the private keys necessary to use the SSL cert. Now imagine that your bank was vulnerable to Heartbleed. The attacker is now able to read off arbitrary 64k blocks of your bank’s webserver’s RAM and given enough time could potentially recover your bank’s private keys.

Now our attacker has the cert and the private key and can set up shop wherever he likes posing as your bank. All that’s left to do at that point is let the logins happen and he can harvest usernames/passwords/sessions to his heart’s content.

So from a consumer point of view, any site on which you care a lot about security (or any site at all really) - change your passwords yesterday! wait until the service has contacted you and informed you that the vulnerability is fixed, and then change your password!

What do regular people do about it?

Need me to repeat it? CHANGE YOUR PASSWORDS NOW.

Update: I jumped on the “change your passwords now” bandwagon, but as a friend pointed out to me it’s vitally important to make sure that the services you use have fixed the vulnerability BEFORE changing your passwords. Wait for them to contact you telling you that they are no longer vulnerable.




Adding firewall rules for Oracle Database using iptables

Posted on March 18, 2014 | no comments

To connect to a box on your network that is running Oracle Database, you will first need to allow connections to Oracle through your firewall.

If you’re running CentOS, RHEL, Fedora or any other Linux variant that uses iptables, use the following commands to create a firewall exception (Assuming you’re running your listener on port 1521 – check with sudo lsnrctl status):

$ sudo iptables -I INPUT -p tcp --dport 1521 -j ACCEPT

Or to limit the connections to a specific IP address – e.g. or an IP block – e.g. use the -s option:
Read the rest of this post…

Tags: , , , , , ,

Apache Tomcat with SSL behind Amazon ELB

Posted on January 27, 2014 | no comments

If you’re running a high-availability system of some kind, chances are you are into some sort of Load Balancing. If you happen to be writing a Java app, and happen to be using Apache Tomcat as your servlet container, then this tip is for you.

I had a system which needed to be HTTPS-only but also have the SSL terminated at the load balancer. Naturally, I forwarded the HTTP and HTTPS ports on my Elastic Load Balancer and had my application configured to redirect any insecure connections to an SSL connection. I started having a couple of strange issues where occasionally it would leave the connection on HTTP when it should have been redirecting.

My setup was basically:

  HTTP (80) -----> ELB -----> Tomcat (8080)
HTTPS (443) -----> ELB -----> Tomcat (8080)

Turned out, I needed to set a couple of extra options in my Tomcat HTTP Connector section. This was the combination of options that did it for me:
Read the rest of this post…

Tags: , ,

Redacting accidental password entries from your BASH history

Posted on August 5, 2013 | no comments

From time to time, I have been known to accidentally type my password into a “username” prompt in a bash shell. In that situation, the password you entered is now a part of your ~/.bash_history file forever, unless you truncate or redact it.

A quick command to do this is

$ history -c

Don’t forget to end your session ASAP as your password will still be stored in memory until you do.

For the truly paranoid (like me), I also recommend changing your password right away, in the eventuality that someone was snooping your session at the exact time that you happened to enter your password in plain text.

Now, where’s my tinfoil hat?

Tags: , ,

Timing PHP code using a simple stopwatch class

Posted on June 6, 2013 | no comments

If you’re writing a performance-focused app, it’s nice to be able to time how long various pieces of code take to execute. Below is the class I use (called StopWatch) and a really simple example of how I use it.

class StopWatch {
   * @var $start float The start time of the StopWatch
  private static $startTimes = array();

   * Start the timer
   * @param $timerName string The name of the timer
   * @return void
  public static function start($timerName = 'default')
    self::$startTimes[$timerName] = microtime(true);

   * Get the elapsed time in seconds
   * @param $timerName string The name of the timer to start
   * @return float The elapsed time since start() was called
  public static function elapsed($timerName = 'default')
    return microtime(true) - self::$startTimes[$timerName];

Here’s a silly example to time how long it takes to sleep for 2 seconds using sleep(2).

  // start the timer

  // sleep for 2 seconds

  // check how long 2 seconds is...
  echo "Elapsed time: " . StopWatch::elapsed() . " seconds";

When I run this on my local WAMP stack, I get Elapsed time: 1.9999310970306 seconds. The results vary, but they’re all as close to 2 seconds as makes no difference.

A better example would be if you were sending a file to a remote location (such as Amazon S3) and you want to find out how long it takes.

  // create a new S3 instance
  $s3 = new S3('my access key', 'my secret key');

  // start the timer

  // read & send the file
  $f = $s3->inputFile('');
  $r = $s3->putObject($f, 'my-bucket-name', '', S3::ACL_PUBLIC_READ);

  // check the result of the operation
  if ($r !== false) {
      // check how long it took
      echo "Elapsed time: " . StopWatch::elapsed() . " seconds";
  } else {
      echo "S3 Error!";

Note: This example uses the PHP S3 class from

This would produce something more like Elapsed time: 3.7492766736612 seconds (depending on how big is obviously. This little tool has come in useful for me a number of times, especially when trying to identify bottlenecks in systems that perform a large amount of juggling with complex data structures. You could add all kinds of other options to it as well, like defining what units to return (seconds, milliseconds, nanoseconds).

Tags: , ,

Transition from glossy to matte UI elements

Posted on June 5, 2013 | no comments

Something I noticed as a general trend with modern technology (especially in mobile development) is a trend away from shiny, glossy UI elements like icons and buttons to a more flat, conservative style.

Here’s a really interesting discussion I found about the subject on the UX stackexchange site

Looks like the main culprits would be Windows and Android, while Apple seems to be sticking with what they know (for iOS at least).

Tags: , ,

A working day’s worth of mouse movement

Posted on May 23, 2013 | no comments

I recently came across a neat piece of software that maps out your mouse movements and creates artwork out of them. Check out the image below – it’s a graph of my mouse movements on my left monitor over a 9 – 5 working day. Click to see full resolution.

I move my mouse around a LOT

The black circles represent times when the mouse did not move – the huge black circle was when I went for a 2 hour meeting.

The software I used is called IOGraphica ( – try it out and see what you get!

Tags: ,