Posts Tagged ‘tracking’

All about the path

October 20th, 2011 Comments off
Reading Time: 8 minutes

Recently on the twittersphere there was a short exchange  as to why would  a security professional care about VXLAN when they don’t care about ASICs in a switch.

In stead of putting the conversation up (I’m lazy and can’t be bothered screen capturing it) I thought I’d share my $0.10 worth here.

In short, you always need to be concerned about the path of data. Just like Network Architects want to know packet paths for engineering purposes a Security Professional also is concerned with what systems or processes does it cross and where are the enforcement (choke) points. But most importantly, you need to know the data path so you can secure it.

I’ll start by briefly explaining what VXLAN is, its deficiencies and then a quick look as to why a Security professional needs to be concerned with the data paths, irrespective of whether or not they are virtual or physical.

What is VXLAN?

VXLAN (IETF REF: is “A Framework for Overlaying Virtualised Layer 2 Networks over Layer 3 Networks“. This is a VMware and Cisco (amongst others) initiative. That’s the fluffy way of saying it is a tunneling protocol, more precisely a L4 tunneling protocol.

Why have VXLAN?

Personally I wouldn’t. It is a VMware kludge to a very specific problem. However, if you are a VMware proponent then you have your uses. For any one dealing with large virtualised environments, especially multi-tennant ones, you will find that you run into the limitations of your L2 network (even a well designed one) really quickly; 4000 VLANs doesn’t go far in multi-tennant environments .

  • How do you migrate VMs across L3 boundaries?
  • How do you move devices about without changing IP addresses?
  • Do all application support the readdressing of VMs?

Let’s take a fairly simple example of vMotion; this is not the ideal example but sufficient to get the concept across. vMotion is the movement of one Virtual Machine (VM) from a physical server to another physical server. Figure 1, below, shows a fairly simple setup with servers connected to the same switch, which we will assume are in the same Layer 2 Domain.

Figure 1 – Servers with VMs in a single L2 Domain

I won’t go into the gratuitous detail on how vMotion works, you can look that up for yourself, but for the VM to move from one physical machine to another there needs to be Layer 2 (L2) adjacency. Figure 2 below shows how the machine is replicated. The path between the virtual Machine on the left (highlighted in Green); through the Hypervisor (in this instance I’ve used VMware) out the physical NIC into the switch; out the switch; into the first NIC of the second server; up through it’s Hypervisor and finally coming to rest.

Stay with me there is a point to all of this.. I hope.

Figure 2 – VMotion path through switch.

Now, throw a router in the middle (see figure 3) and the whole process breaks. Because there isn’t the ability for L2 adjacency, it crosses the L3 boundary, the machine cannot move, let alone retain its IP address, etc.

Figure 3 – VM Servers in two L2 domains, separated by router.


As mentioned previously VXLAN is essentially a tunneling protocol. It is taking a Layer 2 frames and wrapping it in a Layer 4 Datagram, Figure 4 depicts 2 VXLAN networks, green and pink. This, with some other wizardry gets over some of the aforementioned limitations, the virtual machines are tied to a VXLAN ID by the Hypervisor (they need to be the same) which is then passed to the VTEP (VXLAN Tunnel End Point) which then wraps everything in a UDP packet (OK that is slightly simplified).

Figure 4 – VXLAN allows pseudo L2 connectivity across L3.

Now there is an L2 adjacency between the two servers, they can now replicate VMs between each other whilst maintaining the same L2 and L3 addresses. See Figure 5.

Figure 5 – vMotion across L3 boundaries is now possible with VXLAN.

Security Issues:

This is where I hope the rant has some value – If you didn’t care how the protocol works (even in a rudimentary sense) or how the data flowed in the scenarios above you wouldn’t understand what the limitations, and therefore potential security flaws, are or understand what issues it solves. That said VXLAN doesn’t solve any of the existing security issues we find in Ethernet today. It still requires processes to lock down deficiencies in the technology.

  1. Just like Ethernet you can spoofing ARPs;
  2. Broadcast storms still possible (turned into multicast within VXLAN domain);
  3. No security mechanisms built into VXLAN;
  4. If you have access to the network you can spoof anything? If you are on the same network as a VXLAN segment; and
  5. Through the very nature of the VXLAN function you are also now removed from the ability to provide hardware handoff for L2-L7 security measures (think ACLs, VACLs, Firewalls, NAT, Load-balancing, etc). You need to have this gated between VXLAN domains via a VM that spans both.

Even ignoring all these new issues (yes they are new issues, is this a new way of accessing an environment, of course it is!) what about policies, enforcement points, network taps, etc, that may be already in place, in-line/path with the new VXLAN tunnel that you are proposing?

These are all why a security engineer/architect/designer needs to care about the path.

Now to the comment “security guys don’t care about the path through a switch’s ASIC…”, generally speaking, most won’t care, but they should. Just because it is a switch doesn’t mean that nothing happens to a packet once it goes in and then goes out the other side. ASICs are customised, programmable chips that allow the device to perform a number of different functions; if you’ve ever looked into this you will know that no two platforms are the same (even from the same vendor).

In the diagram below (which is a fictitious switch construct) you can see that there are some capabilities built into the different components of the switch, specifically the ASICs.

Getting traffic from one port to another port isn’t necessarily a simple thing. Can I get straight from Eth1 to Eth2 directly, or do I have to go up through the switching fabric to the L2 switching engine? What happens when I have to route (below shows a path of a packet when going via the routing engine)? Does, or can, the packet be modified/duplicated inside the switch and if so what happens? At what point in the packet’s path through the switch is policy enforced, and in what order?

The list goes on and on.

Most enterprise switches, even basic ones, will allow you to mirror ports, I’m pretty sure that Security folk would care about what ports are set up as mirrors and more importantly, what’s at the other end of that port.


The scenario’s above are fairly simple, more advanced switches allow far more sophisticated things to happen. You can rewrite packets, pass off packets to other processors (Routing, Load balancing, Packet inspection, policy enforcement, etc). Again you need to know the path through the switch and what touches a packet to understand the risk and potential impact to that application.


Chris Neal sums up my rant nicely below:


June 3rd, 2011 Comments off
Reading Time: 5 minutes

With the recent media hype surrounding the nefarious tracking of people’s whereabouts I thought I’d take another angle. What are the legitimate reasons for tracking?

The most obvious one that comes to mind is the tracking of stolen property. BoingBoing recently ran a story on the tracking of a stolen laptop with Hidden. I thought I’d play about with one of these tools a little.

I’ve chosen to have a go with Prey as it has a free option and was also used recently to track down the thief responsible for stealing a laptop.

From previous experiences with similar software packages they were costly and painful to install, this by comparison was a dream and was easy to operate.

Now tools like these are a little more feature rich than Apple’s Find my iDevice, but I will say, Apple has done a great job helping their iPhone, iPad and iPod-Touch customers locate missing devices (I had to use it once when I closed my iPhone into a text book and couldn’t find it).

Details of the tool

The installation is as simple as they come, but that isn’t where the fun begins.

Once you’ve registered and logged in to the control-panel you can see your tracked device.

There are a few options that you have for both tracking and alerting. By a few I mean a bucket load:

  • Geo-Location (GPS or WiFi)
  • Network
    • Connections
    • Nearby WiFi
    • Traceroute back to
  • Session
    • Screenshot
    • Active applications
    • Logged in User
    • Modified files
  • Webcam – Snap pictures of the perp for posterity!

As far as alerting goes you can silently watch where they are and what they are up to or you can go the whole hog and:

  • Alarm – Really annoy everyone around, including the perp.
  • Alert – Let them know you’re watching them
  • Lock – Lock the screen and only allow access with password
  • Secure – This is pretty good, it will “hide” email and wipe all password files off your machine.

Compare this to the built in Apple tool that will allow you to Alert, Lock, Alarm and even wipe the device. Again, I’m not knocking the Apple tool, it’s awesome. If they added the same functionality to their the OSX range, I’d be far more impressed.

That all configured and played with I decided to check it out….

Within ~ 8 minutes of clicking go I got my first report and I have to say it was pretty good.

I could see where I was (roughly);

I could see a picture of the environment;

The picture was telling me that my laptop was in an office environment, meaning I could turn on audible alerts and get some REAL attention to the culprit. Yes that is the side of my head working on my other laptop.

I could also see a screen shot of the active webpage, processes, etc. Giving me a good start for tracking the lost laptop.


One gotcha was that I’d not read the control-panel options propertly and found out, the hard way, that alerting functions are enabled remotely once selected, regardless of whether the device is “missing” or not.

Advanced (or Standalone) mode, doesn’t seem to give you as much control. you can manually control the activation of the device (as in it’ll look for a URL, if you delete the page it will start alerting). I like the alerting mechanisms available with the “control-panel” enabled functions. That said it is great that you can have control of devices without going via a 3rd party.


Yes you could technically use these tools for evil, but that could be said about any number of tools out there.

If you are a road warrior, student, hipster-tragic, or other sub-species who has a laptop (or any device really) I can see the value in having such a tool. You never know when you are going to misplace it or have it taken off your hands without consent. As can be seen in the linked articles, these tools have led to th return of devices; what more could  you ask for for $0.

iDevice tracking.

April 27th, 2011 Comments off
Reading Time: 4 minutes

I’m a little late wading into this but I thought it worth looking at based on my last post.

If you’ve been hiding under a rock; Apple tracks where you have been (regardless of your location tracking selection) in a file called consolidated.db.


This was originally discovered by Alex Levinson back in 2010 when he was researching the iPad.

Long story short there is s SQLite Database on both the iDevice (/private/var/root/Library/Caches/locationd/consolidated.db) and stored on your sync machine (/Users/<your user name>/Library/Application Support/MobileSync/Backup/). It uses cell tower triangulation, as opposed to GPS, to track your location (so accuracy isn’t always bang on, but pretty close in most cases).

Recently a couple of researchers from O’Reilly (Alasdair Allan and Pete Warden) wrote an OSX application that allows the visualisation of the stored data and bringing this out from the deep dark recesses of computer forensics to the mainstream, sparking outrage and cries of foul. This in turn forcing Apple to respond to these concerns.

You can see in the image “Tracked!” that it has tracked my movements throughout NSW and Canberra. So I decided to have a play myself to see what is all captured (instructions on how to find the consolidated.db file are on Pete Warden’s site). With the help of an SQLite viewer I opened up the file to see what all was there (see image below):

SQLite file opened

The second table is the interesting one that contains the location tracking data that everyone is interested in. A view into that table shows exactly what can be found in there:

CellLocation Table Contents

I’ve condensed the columns for Longitude and Latitude, mostly because I don’t want everyone knowing EXACTLY where I’ve been 😉

The interesting thing seems to be that there is also similar information being stored for WiFi locations though I’ll need some time playing about to understand how relevant the information stored is, but based on an initial pass it seems to capture any AP that my phone sees. I’ve tested this by pluging random MAC addresses into the Google to check against it’s wireless AP DB and sure enough, these are APs I’ve not connected to but are pretty close to some of the ones I do.

Given the high profile of this, now, and the ease in which the necessary scripts can be located online to grab this information. I suspect that it won’t be long before you see some exploits in the wild and high profile people start finding that their movements are published.

I hope Apple move to remedy this soon.

UPDATE: I forgot to add that Google also track phones and seem to track similar information on WiFi locations picked up by Android devices. I suspect that Apple is doing similar things with the information for their own reasons.

UPDATE2: Apple have released their latest IOS (4.3.3) that addresses some of the issues.

I’ve yet to run it up and review myself but it looks like they have made good. Now to see what happens with Google and Microsoft.