Author: Andrew Hay

Job Search Progress

Since announcing on January 11th that I was actively transitioning out of my role at CloudPassage, I’ve been quite busy. Lots of calls, emails, and onsite interviews, in addition to numerous friends and colleagues offering to help out in any way they could.

After analyzing my week, I decided to post some of the visualizations resulting from my analysis.

Figure 1 – Daily Distribution of Meetings

meetingsperday

Figure 2 – Time Spent Per Company (in minutes)

Duration per company

Figure 3 – Distribution of Meeting Duration (in minutes)

Duration summary

Figure 4 – Distribution of Meeting Type (by date)

Type by DateScreen Shot 2014-01-20 at 8.52.26 AM
I also wanted to point out some of the statistics provided by LinkedIn around who has looked at my profie.

Figure 5 – LinkedIn Search Stats

1234
Good progress for the first week. Let’s hope that Week 2 is just as busy 🙂

The AWS of Things

8982747118_b726398973You’ve no doubt heard that Google has announced it is buying Nest Labs, maker of smart thermostats and smoke alarms, for $3.2 billion in cash. In a very well written NYTimes blog post, Quentin Hardy notes that “Nest did all of it on Amazon Web Services.”

Hmm…interesting. This is the first I’ve heard about Nest running in AWS, though I admit that I’ve not really followed the home automation craze that closely. With this new knowledge, I decided to poke around and see what I could find about the AWS-based service.

A quick Google search for nest firewall ports (which is what I commonly append to a product/application term when looking for what ports are used) provided 433,000 results. Phew, that’s a lot.

After looking at several pages, the general consensus from Nest users was that port 9543/tcp needed to be allowed through their respective home routers for the product to work.

So AWS + a port 9543/tcp (for those of you keeping track at home)

One page provided the FQDN that the Nest thermostat connects to: XXXX.transport.nest.com

According to research by a couple of the forum members:

The nest does frequent dns lookups for something in XXXX.transport.nest.com, which currently maps to an amazon EC2 instance. Then it makes a TCP connection to port 9543 which it seems to hold open. This probably is so that when you go to the nest website it’s able to instantly communicate with your thermostat and not have to worry about your firewall. I think the traffic is encrypted, but it looked like a self signed SSL certificate. I didn’t dig any deeper at the time.

[N]est communicates with the server over 9543. the web client communicates to the same server on port 9443. I would assume port 9543 is just HTTP traffic. The certificate is self signed. attempts at a man in the middle attack to decrypt the ssl packets haven’t worked for me so far.

If you attempt to goto https://XXXXXXXX.transport.nest.com:9543/ in your browser you’ll be presented with the same cert. after that you will be prompted with an authentication window. I haven’t tried using any of the api’s i’ve sniffed from the web client. however i suspect they are probably very similar.

At this point, I decided I had enough information to go on to start my own research. The first thing I did was use nslookup to see what the transport.nest.com provided:

$ nslookup transport.nest.com
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
transport.nest.com canonical name = transport.production.nest.com.
transport.production.nest.com canonical name = transport-service-production-909910888.us-east-1.elb.amazonaws.com.
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 107.20.222.81
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 54.243.109.243

What is most interesting is that Amazon’s Elastic Load Balancing (ELB) is being used, likely to help distribute the load across multiple guest instances.

Using brisket, and Robert Graham’s masscan tool, I started scanning for AWS guest instances with open 9543/tcp ports.

Figure 1 – Subnet to IP Address Mapping for 9543/tcp

subnet2ip

We really have no way of knowing if all of the Nest-related guest instances are represented in the above chart. In fact, based on a host query, at least 3 guests have FQDN’s associated with a non-default AWS public DNS name. Another 5 guests, based on returned banners, appear to be running other applications (such as SSH) on non-standard ports.

Since Nest is a widely adopted product, we could guess that the subnets with the highest number of discovered IP-to-port mappings represent the “Nest Cloud” – but that really would be a guess.

Figure 2 – Top 10 Subnets With Discovered Port 9543/tcp

top_10_subnet
Looking at it another way, the Top 10 count of detected servers look something like this:

Figure 3 – Top 10 Subnets With Counts

subnet_to_ip_square
It’s probably safe to assume that Nest is using VPC given the number of devices it has claimed to have sold to date (~1 million according to a Forbes post). Unfortunately, without getting the device-to-server count directly from Nest, I doubt we’ll ever really know the final number. It’s also probably safe to assume that the IP addresses employed by Nest are load balanced (using ELB) to the servers within its VPC network.

Photo Credit: dailyamazon via Compfight cc

Cloud Data Snapshot – AWS Gov Cloud App to App Stack

Taking another look at the AWS Gov Cloud data I wanted to see what applications (e.g. nginx, Apache, etc.) and application stacks (e.g. PHP, ASP.NET, etc.) were most commonly used for ports 80/tcp and 8080/tcp. The total number of applications (508) far exceeds the application stack count (121) so after eliminating the servers without an application stack (387) we can see the counts below.

Application Server with Application Stack

app and appstack count
How do these map? The Sankey diagram below shows the most common mapping between applications and application stacks on the AWS Gov Cloud.

Application Server to Application Stack Mapping

app_to_stack
My friend Jay Jacobs (@jayjacobs) brought up an interesting idea this afternoon. Why not see what kinds of “popularity contests” exist between applications/application stacks and public/Gov cloud hosting. Maybe I’ll dig into that in the future.

Scroll to top