Others have pointed out that when pushing the “Run” button within QtCreator when the target is set to your N9 or N950, aka Harmattan device it’s very slow. The reason is that it fully builds and packages everything before sending it over. That’s great when you actually want a full package installed, especially when you have modified the C++ internals. However, its a bit over-kill just to install new copies of any QML code. It’s a *slow* process (as is the emulator).

One person has posted a great blog entry for how to speed up the deployment step by not doing the packaging, and just copying the files and running the executable.

But there is even a faster way when it comes to dealing with the QML itself. It involves using sshfs. You simply move your local qml directory aside (assuming that’s where you store your QML code), and mount the n950’s installed filesystem in its place.

devel# cd my-cool-app
devel# mv qml qml.local
devel# sshfs root@myn950:/opt/my-cool-app/qml qml

Now, when you’re inside qtcreator and save the files you’re actually saving them directly to the device. You’ve just upgraded the device with a single Ctrl-S. Done! Now simply launch the app on the N950 and you’re done!

killing/restarting

Of course, the other helpful trick is to launch the application from a terminal window instead.

devel# ssh myn950
n950% killall my-cool-app ; /opt/my-cool-app/bin/my-cool-app &

Just keep hitting the up arrow key to restart the app after you make changes you want to test.

Integrating with git and other foo

git, and most other VCSes, really won’t care if one of the directories has been remotely mounted. It’ll notice the file changes and will let you check in your modifications even though they’re mounted from the phone itself. Just remember when you unmount the phone later (using fusermount -u qmlgit checkout qml), which are likely different than the qml.local directory we saved earlier.

So today (June 8th, 2011), is the first “World IPv6 Day”. This is (was) a day where the techies all over the world were encouraged to try and see what worked with IPv6 and what didn’t. The good news is that the publicity has definitely helped demonstrate that this is an important topic for the future of the Internet. As more and more non-techies are aware, we ran out of IPv4 addresses a while ago (yes yes, I know that is not entirely an accurate statement), and the only long-distance solution is something called IPv6. Which I won’t explain here.

So what did I do to celebrate this monumental event? First, I checked the “who’s supporting it” list and was happily surprised to see a Fairly Long List of participating organizations. Granted, compared to the much longer list of organizations connected to the internet, this is nothing, but it’s a start… Then, I launched my web browser and hit a few random sites to see how they worked over my IPv6 connection. I was happy to see they worked fantastically.

But, I thought, what a boring test. How do I know that my dual-stack IPv4/IPv6 machine is really doing everything it can to reach these sites using only IPv6? I had two choices: pull the IPv4 plug out (no, non-techies, it’s not actually a different plug; sorry for the confusion) or do the right thing and actually test the real data. So I did the right thing. Or at least part of the right thing.

I quickly hacked up a script (now available from my GitHub ipv6day repository) to test a few important elements of how well an organization would truly fair in an IPv6 only world. Connectivity can fail to anyone at any time, and I wasn’t trying to test connectivity. I wanted to test whether they were truly advertising all the needed services of their organization as IPv6 capable. So I tested 3 things (arguably the 3 most important things):

• Did they have a “www” record with a AAAA address (which is an IPv6 address)?
• Did they have at least 1 NS (DNS) entry for their domain with a AAAA record?
• Did they have at least 1 MX (email) entry for their domain that was reachable by IPv6?

Turns out, most sites concentrated on only the first question and skipped the other two. Not entirely a true commitment to testing IPv6. Still, I suppose, better than nothing. But I still won’t list them as “success cases”. If you had only IPv6 on your machine, you certainly couldn’t read their website without at least the first two, and you couldn’t send them mail complaining about it unless you had the last two.

As long as I was at it: DNSSEC

I figured as long as I was testing things, I wanted to test out my ability to use my other new favorite technology: DNSSEC. How many of these domains would at least have:

• At least one published DNSKEY?
• A parent that had a DS record pointing to them?

Note that I wasn’t testing the actual data. Just “if they were thinking about it”, as I wasn’t even checking to see if DNSSEC signatures were being published. And it’s not entirely fair if their parent won’t accept a DS record to publish (but that’s too bad; fix your parent).

Results

The full result table is long. So what do you do with long results? Summarize them of course! So here’s the summary table (the numbers in green are the number of sites that succeeded in all the tests).

It’d be nice if every one of those entries had maximized the IPv6 tests (3) and DNSSEC tests (2). But as you can see, we fell far short of that.

So who gets the gold stars? Of all the 436 domains that had listed themselves as testable, who actually truly tried their best? It’s only fair that I specifically call out “good job” to those that I consider having passed the “World IPv6 Day Test”. These weren’t hard tests. They weren’t even under undergrad course-level worthy. They’re far below questions that might be given during a 101 class test, and were more like a Elementary School course-level test questions. But those that passed are still worth naming.

41 passed the IPv6 test and 36 passed the DNSSEC test. That’s right, of all the companies that said they’d participate in “World IPv6 Day”, only 41/436 (9.4%) passed my simple tests. i don’t think the techie world scored an a+ today.

But, as in every class, there were a few over-achievers. i’ll call out their names as they cross the stage first, because not only did they pass the 3 simple ipv6 tests, they also passed my dnssec tests, which was really a pop-quiz they didn’t know they’d be taking. Kudos to the folks on this list! I passed out the most gold stars to this fine list of students:

Domain	IPv6	DNSSEC	Both
gotanet.se
imperial.ac.uk
lansstyrelsen.se
leissner.se
lst.se

And now the list of companies that at least passed either the full set
of IPv6 tests or the full set of DNSSEC tests:

Domain	IPv6	DNSSEC	Both
afilias.info
antixlabs.com
beamartyr.net
bluecatnetworks.com
broeltal.de
caib.nasa.gov
census.gov
cesca.cat
commerce.gov
cysols.com
dhs.gov
doi.gov
dol.gov
dpf.gov.br
ed.gov
energy.gov
faa.gov
fab-corp.com
feb.gov
gigatux.com
gsa.gov
gustavus.edu
hostingxs.nl
hostmaster.ua
httrack.com
hurricanelabs.com
ig.com.br
iltalehti.fi
indiana.edu
info.info
infoblox.com
inl.gov
internet2.edu
ipv6world.nl
isoc.se
jobs.qualcomm.com
jp.apan.net
kernel.org
km.nasa.gov
lemonentry.eu
lmu.de
lsu.edu
midlandcomputers.com
neustar.biz
nist.gov
nlm.nih.gov
opm.gov
orion.on.ca
pir.org
plurk.com
proofpoint.com
reading.ac.uk
rohitab.com
sanger.ac.uk
skymarket.co.uk
state.gov
supranet.net
t-online.de
tamagawa.jp
thehavennet.org.uk
tunix.nl
ucf.org
ulak.net.tr
ultradns.com
verisigninc.com
w3.org
webmetrics.com

Detailed Results

And for those that want to look at all the individual records, I present the full test result table:

Murphy’s law is typically (mis)phrased as “if anything can go wrong, it will”. My new extension to this law (Wes’ law?) will now read: “If anything can go wrong, it will, at the most inconvenient time” because he didn’t take into account the 4th dimension: time.

Roughly two weeks ago I was wandering around the streets of Prague, CZ when I noticed that I could no longer log into my server back in the U.S. After checking everything leading up to the system, my wife reported “the power button is still doing nothing and no lights are coming on”. I suspected, at this point, it was the power supply. But unfortunately I still had another week of work travel to complete before I could get back to fix it. (And of course, during part of my away trip, I was planning on using it remotely for a work-related demonstration involving DNSSEC).

Hence my new extension: “… at the most inconvenient time”.

Returning to the U.S.

Upon returning to the physical system I did confirm my guess that it was the power supply that died. (Note: in front of the system is multiple surge protectors and a decent UPS, so it was definitely the supply itself breaking, not a surge coming through the power-lines.) I quickly removed the old supply and replaced it with a nice, shiny, dust-free new one. Click Switch, and still no go. Power went to the mother board but it refused to do anything.

Back to the store for a new mother board. And a CPU. And memory. My original estimate of a $75 replacement power supply was beginning to look very very off. After replacing the motherboard, taking out all the original cards and leaving only the original hard drives in place (ok, the physical case was still the same) I tried booting up again. At least the BIOS bootstrapping began, but the system still failed to boot and the screen showing “no hard drives detected” had to be a bad sign.

That left the 3 hard drives as being still in some state of “bad”. So, booting from a Fedora rescue disk, I attempted to examine how each drive was functioning. One at a time. None of them would even spin up. All 3 exhibited complete failure conditions. Two of three were identically configured drives (from different manufactures) in a RAID1 array to ensure that if either drive died, the data would still remain intact. Redundancy is great until everything fails at once. Murphy doesn’t believe redundancy will help. The third drive contained (daily) backups of the system from the other two, but it had catastrophically failed too. That meant that there was no chance of a complete recovery unless I could get at least one of the drives working.

Salvage Operations

That can’t be good

In a last-ditch effort, I ordered brand-new, exact copies of the dead drives (which themselves were only 5 months old so finding duplicates was easy). If I was lucky, only the controllers on the drives would be dead and the physical drives themselves would still function. When the new duplicate drives arrived, I swapped the good controller on a new drive onto a bad drive and hoped. Unfortunately, the first old drive with the new controller still failed (though at least it sounded like it was trying to spin up this time). I crossed my fingers and moved on to the second bad drive. Unfortunately, even that was a no-go. I even tried various other tricks, being at the true “last resort” stage. It’s amazing the things that people suggest that might fix a dead hard drive, from knocking it on a table (I didn’t try that) to pretending to throw it like a frisbee to putting it in the freezer for 30 minutes.

Eventually, I had to admit defeat and start from my oldest, external backups. Sigh. They were from 4 months ago. Double sigh.

It’s better than nothing at least, but… I lost mail. I lost some pictures. And I lost some reputation points from having run a very solid, rarely down, server for various mailing lists and other services for the last 15+ years.

Looking Forward

So what did I learn from this? The first thing: one set of backups is never enough. And most importantly, at least one set should be electrically isolated from the machine. This means that the very common technique of storing backups on an external USB drive probably isn’t wise either since it’s just as likely that the USB system would spike a few volts to the external drive too.

So what are my future plans? I’ve replaced the system and got it back up and running on the old data, restarted the backup system using the exact same nightly routine. But now I’m going to add an external USB drive to a completely different machine and (r)sync the backups to it on a daily-ish basis. That combined with a backup MX server that keeps mail copies of critical domains for 30 days and off-site backups of truly critical data should suffice right?

Shush Murphy. Yes, I can hear you whispering behind me, but I’m not on speaking terms with you right now.

Recently I ran into two different cases of other people running other networks that affected me directly in a negative way. Now, we all know that people make mistakes and hardware failures can and will happen. However, in these two cases it wasn’t from “broken code” but rather “broken as designed”. The IETF, a standards organization that I’ve spent some time working with, goes through lots of thought and trouble to design internet protocols so they’re interoperable if you follow the rules. The problem is that sometimes network administrators decide they can “hack around” the way a protocol is supposed to work in order to achieve some goal. Frequently, however, they miss critical aspects of how the protocol is supposed to work or (worse) consciously ignore how protocols are supposed to work because they don’t care about the other networks they break. As long as they’re not breaking their own, of course.

But, to begin my story, I think I need to first highlight the important protocols I’ll be talking about.

The Players

• IPv4 and IPv6: These are the big players these days when it comes to “things that are going to break on their own soon”. IP addresses are those silly string of numbers that tell the internet who you’re actually sending packets to. Normally, the average Joe doesn’t think about these because the average Joe is lucky enough to type “Domain Names” into their web browser instead of silly strings of numbers. The thing you need to know about IP addresses is that in the near future (possibly by the time I’m done typing if I don’t hurry up) we’ll run out of IPv4 addresses to hand out to things like your cell phones, washing machines and toasters. Unfortunately much of the world isn’t ready for the transition from IPv4 to IPv6, even though it’s been coming for a very very very long time. We all procrastinate, after all.
• Domain Name System (DNS): The DNS is how we translate those useful names (like pontifications.hardakers.net into silly numbers. Like 67.205.57.145. Or 2001:470:1f00:187::1 (yes, those really are all numbers if you expand your mind a bit).
• Simple Mail Transfer Protocol (SMTP): This is the guy that is making post offices around the world quiver wondering when their funding from selling postage stamps will dry up. Although this E-Mail thing has been catching on, we’re also finding that more and more people are relying on other services now, like FaceBook, for communicating instead. Interestingly enough, both of my issues below relate to communication. One with E-Mail and one with FaceBook.
  

  Enter the Era of E-Mail

  Now, E-Mail, it turns out, gets sent around quite a bit. I know that I still get quite a bit of it these days. Unfortunately, some entrepreneurial folks have figured out that the powers from the dark side enable them to use E-Mail for negative reasons as well. I’m speaking of SPAM of course, which currently accounts for about 75% of my E-Mail. [On a side note: I suspect that spam via paper-mail (otherwise known as bulk-advertising) is the one thing keeping most of the world’s post offices still in business.]

  Now, unless you’re a protocol geek like I am, you may not know that E-Mail that needs to get sent from one server to the next also uses DNS records that translate human-readable domain names (like hardakers.net) into IP addresses (like 168.140.236.43 and 2001:470:1f00:187::1). So, lets say you need to email youraunt@hardakers.net the first thing that your ISP does when you ask it to deliver a letter is to look up the IP address.

  What’s supposed to happen

  Normally when you look up where to send something you’ll get a few answers, nicely prioritized by where you should try them first:

   # dig +short hardakers.net mx
   5  mail6.hardakers.net.
   10 dns66.hardakers.net.
   20 dnsm3.hardakers.net.
  

  This shows us (or more appropriately, your ISP) to try and send the mail first to mail6.hardakers.net (priority level 5) and if that fails to trydns66.hardakers.net and then finally to dnsm3.hardakers.net. The server then starts by looking up the numeric address for the first one and then trying to talk to it. If one doesn’t work, it should skip to the next one an keep trying till it has no more to try and then will give up. (And by “give up” I mean, “keep trying for another 7 days or so at regular intervals”.)

  So, lets look up the address of the first one. We’ll look up both the IPv4 and the IPv6 address for it:

   # dig +short mail6.hardakers.net A
   # dig +short mail6.hardakers.net AAAA
   2001:470:1f00:187::1
  

  Note how, in this case, there is no IPv4 address (the line ending with an A didn’t get an answer). There is only an IPv6 address (the answer to the line ending with AAAA). This is perfectly legal, and was actually set up this way intentionally. I wanted to be ready for the cometh of IPv6 and was encouraging mail agents around the world to try me first over IPv6. I thought that was rather good of me: exercise early, exercise often (which reminds me: I’m late for my bike ride).

  So, this has been working quite well for many years (I’ve been quite anxious for IPv6 to take off). Not only that, it likely even reduced some of my spam since many spammers don’t try the remaining listed addresses and rarely have IPv6 support. Spammers don’t even pretend to be compliant with anything. Especially morals.

  Enter btconnect, a UK ISP

  BTConnect is (supposedly) the biggest ISP on the other side of the pond from the United States. They decided to add in another rule to the SMTP protocol: every MX record MUST point to a valid address. IE, you couldn’t create a record for bogus.hardakers.net and use it as an MX record without adding an IP address for it. They did this to try and ensure that the remote address was legitimate and then refuse to send it for their customers (folks like you and me sitting at home on couches; they’re just British couches) if it couldn’t do a proper address lookup. But it turns out a lot of people (who now hate BTConnect) were intentionally putting in fake MX records with no matching A record to try and subvert spammers. The end result is that BTConnect clients are unable to send mail to any domains that were fighting spam in this way. I’m not going to argue which side is being legal here. They’re both doing things that are “unintended”.

  But what’s worse is that BTConnect assumes that the whole world is IPv4-based and treated my perfectly legal AAAA-only record mail6.hardakers.net entry as bogus. This prevented an associate from being able to email me (about designing protocols, ironically). Bad Bad BTConnect! (no bone!) You need to get with the game, because the IPv4 game is about over at this point. And stop hacking protocols because you’re affecting your client’s ability to conduct daily business by sending legitimate E-Mail.

  Enter the (new) Era of Facebook

  Facebook (unfortunately, IMHO) is trying to get everyone to communicate with each other solely through their website. The good news is that they’re actually trying to be up on the IPv6 front and even have an IPv6-only version of their website available. (If you can visit successfully it means you and your ISP is IPv6 enabled. But you’re probably not since 99% of the ISPs out there are not yet compliant).

  Now, many people are actually paranoid about deploying IPv6 enabled infrastructure too quickly and often attempt trickery to try and ensure that if some user out there is trying to get to them that they can. Rather than trust a user’s ISP to have correctly set up IPv6, they assume that all other ISPs out there are IPv6 broken even if they might not be. To reword that in simple terms: many places try and intentionally prevent you from reaching them over IPv6. Because they trust IPv4 and “just aren’t sure” about IPv6 yet. Hence the reason you have to go to a different domain name if you want to use IPv6 with Facebook, and they’re default web page (www.facebook.com) isn’t IPv6 compliant.

  Facebook does this IPv4-only hack in a bit more tricky, and DNS-illegal, sort of way. Here’s the nitty gritty details that will make DNS-experts cringe (but most other people won’t catch the problems). First, this all has to do with apps.facebook.com, which is where Facebook sends you to get your virtual hands dirty by tending to your screen through planting green pixels into fields of brown pixels. So, lets see what it takes to look up address records for apps.facebook.com.

   # dig @glb1.facebook.com. apps.facebook.com AAAA
   apps.facebook.com.      30      IN      CNAME   star.facebook.com.
  
   # dig @glb1.facebook.com. apps.facebook.com A
   apps.facebook.com.      30      IN      A       66.220.153.28
  

  Now, the DNS specialists here will immediately point out that what you see above is illegal in the DNS protocol world. My co-worker, who has memorized the RFCs better than I have, nicely extracted the right quote about this:

   "If a CNAME RR is present at a node, no other data should be 
   present; this ensures that the data for a canonical name and its aliases
   cannot be different.  This rule also insures that a cached CNAME can be
   used without checking with an authoritative server for other RR types."
  

  To reword that in simple terms: you can’t have a CNAME and an A name existing for the same record (even for different query types, like A and AAAA).

  Now… Did this break something? Yes.

  First, I found one web-browser/DNS-stack combination that refused to go further. The instant it got a serious error with a record while searching for an IPv6 address, it gave up and didn’t try to find an IPv4 address. Not exactly wise either, but not illegal. Ironically, this was the exact sort of thing that the Facebook DNS hackery is trying to prevent: the customer not getting to the site. And some green electronic crops probably turned brown and withered. Electronically.

  This DNS hackery also causes the most popular recursive name server in use today to be equally as annoyed with AAAA queries:

   # dig apps.facebook.com aaaa
   ...
   ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31717
  

  Update: 2011-01-26

  They seem to have now realized that the above breaks thing. So they’ve started doing different illegal things in hopes that it would magically start working.

  # dig @ns4.facebook.com. apps.facebook.com ns
  ;; AUTHORITY SECTION:
  apps.facebook.com.      30      IN      NS      glb2.facebook.com.
  apps.facebook.com.      30      IN      NS      glb1.facebook.com.
  
  # dig @glb2.facebook.com. apps.facebook.com ns
  ;; ANSWER SECTION:
  apps.facebook.com.      30      IN      A       69.63.189.62
  

  Yes, you read that right: query for a NS record to ensure it’s accurate and you get back an A record instead. That’s what you really wanted, right?

  Conclusions

  The biggest conclusion here: if you’re going to hack, do so to speed things up. Do so to make things better. Do so to make things more interoperable. But do not assume that you’ve considered all of the corner cases with a protocol when you decide to modify the rules. The results will likely be less customers reaching your service, not more.

  Oh. And IPv6 is coming. Please get ready. But without the hackery.

SNMPv3/USM, unfortunately, does suffer from some elements of man-in-the-middle attacks. But these are poorly understood and certainly not well documented (if at all). This document attempts to describe the weakness inherent in the SNMPv3/USM protocol.

Background and Conventions

Although this document coves some of the necessary background, it’s still expected that the reader already understands how SNMPv3 with its User Based Security Model (USM) works. The details of the SNMPv3 protocol and the USM-subprotocol aren’t discussed in this write-up.

It’s also expected that the reader is familiar with the USM concept of “discovery”, which can be summarized at a high level as this: a manager is allowed to send a “probe” message to an agent and the agent should return a “report” message that says “I’m using securityEngineID 1234”. An important element of this discovery request and response process is that it’s fundamentally unauthenticated. There is no proof that the agent responding actually is the right agent. The belief is that because future requests and responses are authenticated and use a key only known to the agent the manager wants to communicate with that the unauthenticated discovery request isn’t a big deal. But, in fact, it is and it does open the door for certain types of man-in-the-middle attacks.

USM contains a key-localization process provides the ability for the administrator to provide only a master password or a master key and the management software can transform that key through a series of one-way hashes into a key which is unique to each agent that the packets are destined for. Though this does prevent keys stolen from one agent from being used to break into another, it doesn’t help in the problem described below as will be shown. It won’t matter if the key localization process is used or not; they could have been randomly generated for each remote agent.

For documentation simplicity I’m only showing the use of one key in this document. But in SNMPv3/USM there are actually two: one for authentication and one for encryption. For purposes of the discussion, however, we can treat the keys as a “pair” and any time one is affected then so is the other.

SNMPv3 also has the notion of a contextEngineID, which is not discussed in this document as it is not relevant. Only USM’s specific securityEngineID is relevant to this discussion.

Typical Real-World SNMPv3/USM Start-Up Sequence

Pictures are always easier to understand, so let’s pretend we have the following network setup. Agent B will be colored red in these pictures since in the examples below we’ll consider it to be a machine which has been taken over by an attacker.

Typically a management station starts talking to an agent for the first time over SNMPv3/USM it will send an an securityEngineID request. And, of course, the agent sends back a response with its own securityEngineID:

At this point, the management station can start sending authenticated and encrypted traffic to the agent by using the authentication and encryption key assigned to the given securityName for the remote agent. Each agent has its own unique key pair that the manager uses to communicate with it and internally the manager has a table (the usmUserTable) of all the users and keys for the agent it wants to talk to.

The Attack

The problem with this situation is that the manager uses two values in order to look up the key for a given communication.

1. It uses the securityName value it was given by some dialog box or command line option. In these diagrams this value is “userJoe”.
2. The securityEngineID that it potentially learned from the discovery process.

But Discovery Results Aren’t Authenticated

Assume in the diagrams that Agent B has been compromised and it’s keys are now known to the attacker. Normally traffic sent from the manager to Agent A should be authenticated and encrypted with Agent A’s keys. This means that Agent B shouldn’t be able to see or respond to requests sent to Agent A because it doesn’t know the right keys.

But, if an attacker has compromised a device that is able to see traffic destined for more than just itself (e.g. when connect to a hub or truly in the middle of the path) then there is a problem if it can also spoof traffic. All it has to do is spoof responses to other addresses with its own securityEngineID for any securityEngineID probe that comes it can see. It will have to do this faster, of course, than the real agent can respond (but that can frequently be easily helped by launching DOS attacks). The end result is that the manager will get back a packet in response to it’s securityEngineID probe with a packet that looks like it was from Agent A but internally has a securityEngineID for Agent B.

Now, the manager thinks it has the right securityEngineID for Agent A, but in fact has the wrong securityEngineID for it (i.e. it has “engineIDB”). It uses this securityEngineID (“engineIDB”) in combination with the operator-provided securityName (“userJoe”) as indexes into it’s user/key table to figure out which key to use for protecting traffic. This look-up succeeds in finding a key, but has in fact found the wrong key for the agent it wants to talk to (Agent A). Instead, it finds Agent B’s key and starts its communications using KeyB.

Agent A will actually drop any requests that fail authentication (possibly sending a notification; but more on that later). But Agent B no longer even has to beat Agent A’s response back to the manager so there won’t be a race any longer and Agent B has successfully captured the entire communication stream until the manager looses its knowledge of Agent A’s securityEngineID again.

What Power Does This Leave Agent B With?

This only buys Agent B two things:

1. The power to receive and decrypt traffic that was intended for Agent A. Typically GET and GETNEXT requests from a manager shouldn’t have anything but OIDs in them (though from an analysis point of view it might contain information about what functionality Agent A is supposed to have). SET requests, however, might have more interesting information encoded into the values that might be worth “stealing”.
2. The power to spoof Agent A and return fictitious data from it. Agent B can now adequately pretend to be Agent A and thus can return bogus data as well as pretend to have acted as if SET requests had really been processed. This lets untold number of bad things happen, including convincing a management station that a device is fine when it really isn’t, under-reporting bandwidth usage, etc…

Protecting Yourself From The Attack

There are only a few choices when considering what to do about this attack:

1. Understand the weakness and be OK with it. Just don’t be ignorant of it.
• Understand that:
  • Management data sent from the management station can be stolen.
  • An agent can be “spoofed”. A management application may think it’s talking to agent A which has possibly:
  • Accepted and acted upon SET data.
  • Has returned real and true values that you can trust to be from that agent.
• Protect yourself as best as possible:
  • Leaving your management applications long-running so they memorize securityEngineIDs can be helpful (though if the attacker succeeds at any point, you’ll believe he’s the right agent for a longer period of time so it’s still a trade off).
  • Doing a “leap of faith” type approach and believing the first securityEngineID and expecting it “from then on” (even if the management station is shut down; though I don’t know of software that stores securityEngineIDs in persistent storage.).
2. Don’t use the securityEngineID discovery process and pre-populate the management database with the real expected securityEngineIDs extracted from their consoles. Unfortunately, this doesn’t scale well. And thus I don’t know of a single person who actually manages their network this way.
3. Use different securityNames on every agent. Unfortunately, this doesn’t scale well either. I don’t know of a single person that manages their network this way either.
4. Use another form of SNMPv3 security, such as SNMP/SSH transport or the upcoming SNMP/(D)TLS transport. These forms of SNMPv3 don’t suffer from this weakness but have only recently been defined by the IETF and aren’t widely implemented and deployed.
5. Only run management commands over a protected physically separate and entirely switched network. Fortunately, this is frequently common practice. Though it doesn’t necessarily eliminate the threat depending on which network components have been broken into, it should help reduce the threat significantly.

Questions and Answers

Does This Attack Work If Not Man-In-The-Middle?

The short answer is “no”.

The longer answer is that if the attacker can’t see the traffic, then they’d have to be able to guess the manager’s messageID and time the securityEngineID response appropriately.

But even if they could do that, it doesn’t help much unless they can see the traffic since they won’t see what they can now decrypt and respond to. The attacker can’t easily respond to what they can’t see (without an unreasonable amount of guessing of packet contents and timing).

The best an attacker can hope to accomplish would be a denial of service attacker because the manager would fail to communicate with Agent A while the securityEngineID mismatched.

What About Authentication Failed Notifications?

If all the agents are configured to send out SNMPv2-MIB::authenticationFailure notifications then in theory the manager would receive a notification every time agent A received a packet that wasn’t authenticated with the proper key (keyA).

This is true and maybe helpful if authentication-failure notifications have been turned on. But the evil Agent B entity may find it possible to spoof securityEngineID query responses from the management’s notification receiver to stop INFORM notifications from being encrypted with the right authentication key thus causing the notification receiver to drop the notifications. TRAP notifications are sent using the local (correct) engineID so this attack won’t work on them.

Many of my friends and family have been confused over the differences between Facebook and Twitter. (Most of the confused use one and simply don’t know what the other is). There has also been a lot of speculation on the net about how Facebook has been slowly trying to take on twitters surge in popularity through their adoption of Twitter-like-qualities.

This write-up documents some of the important differences between the systems so that you can decide which is best for you and how you should think about using each one.

First the Similarities

The core part of both Facebook and Twitter surround “status messages” that you and your friends post to stay in touch with each other. Messages like “just got back drom the new star trek movie” will frequently start an online discussion between those you know about how successful the new film was as a “reboot” of the old series. More boring messages like “I just woke up” will only stir up the electronic version of crickets and will provoke little conversation.

On to the differences…

Openness

Facebook was designed as a web-browser based service: you log into their site through your web-browser to see status updates from your friends mixed with their advertisements.

Twitter has, since it’s early days, provided a programming interface (API) to it’s service. This interface let’s programmers write applications that check for new tweets, submit your own status messages, etc, all without actually visiting Twitter’s web page. The result is that there are many many applications and ways to interact with Twitter content besides just navigating to the twitter web page. The most popular ones tend to be the ones that sit on your desktop or in your toolbar and notify you when new tweets arrive.

Openness of the Data

By default, Facebook hides all your data so only friends (and approved game applications) can see your status updates and personal information.

Twitter is the opposite though, for both good and bad. It defaults to posting your messages publicly for the world to search through.

This, by far, is the biggest in usage differences. If you end up using both systems, just think before you post who your audience is. But more importantly, I like it this way. There are many updates that I post to both systems because I either don’t care or actually want them heard widely. The announcement for this blog posting, for example, I’ll submit to both services. I also tend to post smaller and more frequent comments to just Twitter. And much more personal comments to just Facebook.

Update Frequency

Because of the open API and extensive external application support, Twitter is more in your face 24/7 and integrates into your day rather well. The result is kind of a constant connection feeling with lots of friends, services and celebrities. The ability to tweet quickly in seconds is always present because somewhere on your screen you already have an open box waiting for you to type in your latest pontification. There are even application plugins that monitor what you’re doing and provide a tweet on your behalf (such as every time your music player switches songs). Many early tweeters make the mistake of tweeting way too much and let you know all about their third bite of a taco bell buritto you probably don’t care about. (They also quickly lose their followers). The better twitterers post only interesting thoughts and activities.

Facebook on the other hand is designed for less frequent status updates and less frequent review of your friend’s updates. Most users log into the site a few times a day, respond to the discussions, update their status (maybe) and play a game or two. It’s designed to be a “visit when I have time site” and is not designed to let you know that your BFF just put on her left sock.

But the instant notification ability of Twitter is what makes it far superior for service broadcasts. Many important services today have twitter feeds for major events (eg, the White House, the RedCross, CNN Breaking News or even Earthquakes that occur near San Francisco) so that you can be instantly informed about events happening at a given instant.

Twitter has also always had the ability to send and receive cell phone text messages. You can have the service text you when your favorite friends update their status and likewise you can update yours by sending a text too. Many smartphones have Facebook applications or web browsers, but twitters SMS tie-in is, again, designed to make you feel continuously connected (no matter how old your phone is).

Status Update Size

Twitter messages have a size limit of 140 characters, which isn’t much (note how easily it fits into a 160 character SMS message? Surely their choice of size was deliberate!). Twitterers learn to abbreviate and be witty in a very small space.

Facebook, however, lets users write multiple paragraphs about their current thoughts. This works much better for ideas you just can’t convey in a short burst. Twitter is referred to as micro-blogging, and Facebook is in between Twitter and a full-size, long-winded blog like this one.

Data vs Presentation

Another major difference between Facebook and Twitter is the presentation. Twitter is all about the content and the data. It doesn’t concentrate on presenting it in fancy graphics on their site (though many desktop applications actually look much better than the Twitter home page). Twitter just wants to bring you data fast and it excels at doing just that.

Facebook, on the other hand, is a complete package. It’s like the “Hotel California” as it wants you to never leave. It’s entrance hall is splendidly decorated with fancy graphics, profiles, pretty colored reply boxes, etc. Every link from Facebook tends to take you to another Facebook wrapped external page or application so you’re always encouraged to return to Facebook immediately. But, their web interface is a beautiful blend of simplicity and function (apple would be proud).

Twitter is also just status messages only with no extra features, while Facebook is constantly tempting you to take a new quiz or play a new game. Facebook’s interactive and highly-addictive multi-player games are wonderful distractions and suck up hours of your time. Twitter almost seems dull after having spent an hour trolling around Facebook’s site.

So which should you use?

You’ve probably guessed my answer by now: Both!! I have both a Facebook and a Twitter account and use them both daily. I love them equally, but for very different reasons. Facebook is a collection of conversations with friends and family. But Twitter has actually helped me make new friends through it’s openness.

The truth is, they’re very different beasts that serve fairly different purposes. Regardless of what Facebook does to become more Twitter-like it may not matter if the users don’t want or use the Twitter-like changes (I for one like the differences). If Facebook adopts many of the Twitter attributes of openness it will mean losing out on an important aspect of Facebook: your status updates go to your friends and family and people you trust.

So I suggest you try them both and hopefully you’ll even use them both. They’re free, after all. What do you have to lose (but time)?

These days if you play FarmTown and you visit “The Marketplace” in order to sell some goods, get hired, or whatever you’re likely to find occasionally that random people follow you back home to your farm when you leave. This seems a bit odd to many people. I mean, if you go to your local grocery store and some random person followed you back to your house you’d probably call the police right? In fact, this is the whole reason we have these things called “locks” on our front doors. To prevent everyone, including friends, from randomly entering our house. Farmtown, however, doesn’t have locks. (Fortunately there isn’t much they can do in your farm so it’s not really a huge concern)

Why people are doing this in facebook too I’m not sure. I suspect that they’re looking for a job (ie, they want to work in your fields for cash) and they’re hoping you’ll hire them.

My Wife’s Solution

So, my wife had a smart idea: never hire them. In fact, make sure you can’t. She does this by clicking on them and then clicking “ignore”. By doing this you add them to the list of folks that are functionally “banned” from your view of the game. The result is that no matter how much they beg you for a job in the marketplace in the future, you’ll never see them and will never hire them. Plus they immediately disappear from your farm as well.

I thought this was a great idea to solve the annoying-farmers problem.

Cheat??? Why??? Well, after posting my previous blog entry about FarmTown cheating I noticed a huge number of Google and other search engine hits by people looking for “how can I cheat at FarmTown”, etc. Apparently I’m not alone in the desire to overcome FarmTown boredom.

There is a huge amount of wonderful pages devoted to farmtown data, but not as much about advice about how to play efficiently. For those just looking for how much stuff costs, what level you get it at, etc, I recommend
Uncle Joe’s Farm Town Addicts Site

Today’s Progress

While working diligently away on my farm today and jumping from level 19 or 20 (I forget) to level 24 I:

• Ate a wonderful father’s day breakfast with my family that was prepared by my wife
• Filled up the car with gas
• Packed the car
• Went shopping
• Played a game of pool
• Read to my daughter

Motivation

Well, simply put I wanted to be level 27 so I could buy rivers. I didn’t get all the way there today, but I made a good leap forward. The problem with farmtown is that after the first 15 levels or so it gets very boring when it comes to the farming aspect itself. Not the building pretty pathways and stuff aspect, but the aspect of cultivating a huge set of crops just to try and get more experience points.

This, in my opinion, is a fault of FarmTown’s. They should, after a certain level, make it easier to clear and plant a field full of crops with one “select a rectangle” type motion. It’s cute when you first start to plant each square, but boy does it get boring by the time you get up there in levels. And because levels get harder and harder to achieve the level reward is less and less (aside from the financial increase, which is constant).

FarmTown isn’t the only game with this problem. It dates back to any large “build an empire” type games including empire (the old ascii text game for those that remember it) to warcraft and to the latest in the line: FarmTown. Maintaining a huge set of maintenance tasks gets dull and dry.

But… I really wanted to be level 27. I just didn’t want to spend the time.

Enter The Cheat

Ok, it’s not a “real” cheat. It’s well known, as I’ve discussed previously that you can turn FarmTown cash into FarmTown experience points. The cheapest way to do this is by adding hay bails to your farm. At the end cost of roughly 1 experience point per 10 FarmTown coins spent the hay bails are the best return.

But, it’s boring putting out a gazillion hay bails too, so why is that any better? It provides you increased speed at yet more boring work.

Or does it. I handled this by recording mouse clicks with a mouse event recorder and then playing them back. I’d buy a hay bail and then sell it. And then tell my computer to repeat the process over and over for me while I went and did something else.

Sure, occasionally it would mess up and start trying to place a bail on another, but in general it worked and I got a lot of house-hold chores done instead! Yay! I’m level 24 now!

So if you want the amount of coins you have divided by 10 in experience points, you might give this approach a shot. I don’t have software to recommend to you (see below for my linux notes) but I’m sure if you search for some for your OS of choice you’ll find something. I know stuff exists for windows, and I suspect for OSX as well.

Advice for FarmTown Developers

Don’t get mad at the people that want to cheat. Fix the issue within the game. I’ve noticed that a lot of my friends simply stop playing near level 28 or so because it’s just boring after that. You’ll loose customers unless you can fix the boring aspect of the higher levels. Add something else for them to do instead that captures their interest again.

Final Linux Geek Note

Turns out that all the linux event recording software is dated and doesn’t work. There is some playback software though. I wrote a quick script to wrap around xte from xautomation to record and then replay what I needed.

[Update: make sure to read my follow on article as well: How I Cheated at FarmTown Today]

Any game, is of course, accompanied by a number of different ways you can attack the problem of “how do I get a high score as quickly as possible”.

Facebook’s FarmTown game is highly addictive to many people and some of my friends have spent endless hours carefully laying out rice fields for harvest two days later.

Status in FarmTown

There are really only two things worth achieving in FarmTown: Money and Levels/Experience Points. Money is earned by planting and harvesting crops (or better yet, having someone else harvest your crops for you). And, if you harvest someone else’s crops then you get some extra cash too (it’s a good deal for both sides). The fastest way to get cash is to go hang out in the market place and beg people for jobs harvesting their fields.

But experience points you only get by either plowing, planting crops, visiting friends farms, or building infrastructure. Now, you can only visit your friends for experience points roughly twice a day. And there is only so much space on your farm so after you’ve filled you soil with crops and farming infrastructure (virtual barns, paths, scarecrows and hay bails) you have to sit back and wait until the crops are ready.

Or do you…

[Update: as people have pointed out in the comments and as I discuss in How I Cheated at FarmTown Today using hay bails for converting cash to experience points is more efficient]

Many people have figured out that planting grapes earns quick experience points because in 4 hours their ready again. Yes, they’re not worth much but they do turn around quickly. Thus if you’re shooting for straight XP then grapes seem like the right way to go.

But there is a better way:

1. Plow your whole field per normal (20 coins per square and it’s worth 1 XP)
2. Plant grapes in your whole field (also 20 coins per square and it’s worth 2 XP)
3. Buldoze them over immediately (gasp!!!)
4. Go back to step #1

(and for you slashdot readers add in “Profit!” somewhere)

See… If you’re willing to spend the cash (40 coins) and the time (something you’ll admittedly never get back) then you can earn 3 XP points per square. Quickly. Keep repeating till your out of cash. You’ve probably just levelled up quite a bit.

When you run out of cash, go to the market place and beg people for a job to get more cash. I bet following this formual you could go from level 1 to level 20 in a day without breaking a sweat on anything other than your index finger.

Begging for jobs

Having done a bit of job begging, here’s my advice: be smart, be witty, be silly. You’re much more likely to get a stranger to hire you than if you just keep chanting “hire me”. When I’ve simply made funny jokes about wanting to get hired I’ve gotten jobs much faster than the others around me that were closer to “annoying”.

After all is said and done

Go outside into the real world and mow the real lawn. You probably need it at this point.

Many people have asked me in the past to explain how in the world I handle so much E-Mail. Since it’s such a long story consisting of many parts, I rarely answer it. Also because I think it’s easier to describe using diagrams, examples and sciency looking graphs. In fact, it turns out, that even describing how much mail I get, and why I get so much, is a story in itself. So this is part #1 of like 2 that describe my E-Mail setup. This first part consists entirely of a description of how much mail I get in the first place. Believe you me, it’s quite a bit.

So, how much raw E-Mail do I get?

So before this, I actually wasn’t even sure. It turns out that the answer is simply put as “a lot”. A whole heaping lot. Much of it is, of course, spam (I don’t have an exact percentage at the top of the article). But even assuming that it’s 90% spam, which likely isn’t the case, I still receive a lot of mail. And it’s all my fault because, simply put again, I want that much (gasp). Ok, maybe not the spam.

So let’s start off with some (sciency) graphs showing the raw numbers of E-Mail that I attract. To really understand it all, I need to break it down into chunks and study each piece.

The Long Haul: Mail Per Month

The first graph below shows the amount of mail per month that I received over the last year-ish.

Mail Per Month

The important thing to notice in the above graph is that the amount of mail I receive isn’t even consistent month to month as it ranges from 6500 in a month to almost 13,000. Sure, February has less days in it so you’d expect it to be lower because all months were not actually created equal. But even those slight variations don’t account for the huge swing in differences from month-to-month. Some of it certainly is because my work-load with respect to communication comes and goes. Some months I simple receive a lot more mail for work related projects than other months (usually as deadlines approach and panic ensues).

But the biggest reason for the fluctuation is that spam comes in waves too. Just looking at my day to day E-Mail it’s always amazing how much the incoming spam varies. Some of my email addresses (I have many) are widely published and thus widely harvested by the evil address-collecting spam machines. This results in a huge amount of my mail being spam, unfortunately.

But beyond that, you can see trends in the graph where, for a while, there was a significant drop in incoming E-Mail. This was because a major spam ring was taken out of service a while back and that’s where the huge dip comes from (you should have had a spam dip in that time frame too). However things are unfortunately back to spam-normal again. Do you feel like all of a sudden you’re getting more spam than you used to? Well, you’re not alone. Eventually the next spam king-pin took over and we’re back to an abysmal spam rating of something like 90% on-average spam. The peace was nice while it lasted, but now I’m back to evaluating whether my rich Nigerian uncle really did leave me a fortune or not. Fortunately if he didn’t, it turns out I have 1094 other rich Nigerian uncles who also amassed a small fortune if only I could pay the wire-transfer fee to get it safely into my bank account.

The Shorter Haul: Mail Per Day

The next graph shows the amount of mail per-day that I received mostly during the month of May (2009).

Mail Per Day

There are a couple of interesting actifacts that you can hopefully spot in this graph as well. You’ll notice that has a definite repeating cycle. The cycle is simply this: the low spots are on the weekends. I.E., by far the most mail I receive comes during the work week. This isn’t surprising to me since much of the mail I receive is work related in the first place. Which begins to tell you how much mail I receive for work-related purposes.

Ok, But What Exactly Is It All Then?

There’s the real question. If I get bombarded with so much mail, how much do I actually read??? So, lets pick a day. Ok, let me pick a day since you couldn’t help me there. I picked June 3rd, 2009 which is a Wednesday.

On Wednesday June 3rd, 2009 I received 4514 individual pieces of email. Now, lets quickly do the math shall we? If I tried to read all of that and I did so in, say, a 10-hour period (8 hours for work and 2 hours of reading just the personal mail) that would be 4514/(60*10) = 7.523 email messages per minute that I would have had to read. Though that might be possible if they were all short, I assure you that the people I correspond with are not well known for writing short, brief messages. Long winded rants are, unfortunately, much more common.

Weeding Out The Spam And Rich Uncles

So, the first thing we need to do is remove the auto-discarded spam and duplicate messages (I have a nice filter that removes duplicates so that I’m never bothered twice because someone put me on both the To and the CC line or because I’m subscribed to multiple mailing lists that the message went through). It turns out that in the 4514 messages, I auto-discarded 3163 of them. That’s roughly 70% of them. Since that’s most likely spam, that’s probably close to the real spam percentage that I receive: 70%.

Looking At What’s Left

That leaves only 4514 – 3163 = 1351 messages left to handle. And if I had 10 hours to sift through 1351 messages in my INBOX I could do so at the leisurely rate of 2.25 messages per minute. That’s almost doable (at least if I blacklist a few of the people that mail me the most long of the long winded rants).

But here’s the real secret. Of all those 1351 messages, only 10 actually ended up in my INBOX. That’s important, so let me repeat it. In bold. Only 10 messages actually ended up in my INBOX. And there’s the secret to my success: everything else gets filtered out and placed somewhere else. In fact, if you really look at how I treat mail it turns out I have lots of INBOXes. The one that only received 10 is the one that is just mail sent to my personal account. My work addresses only received 16 to the work INBOX equivalents.

Dealing With Mail in Clumps

So what is really happening, behind the scenes, is that my mail for the day actually got sorted into 44 different places. Not just 1 or 2, but 44. That lets me sort and prioritize my mail so that the important stuff I can see right away in small INBOXes and they don’t get lost in the bulk of the rants.

In the rest of the mail: 638 messages went to a folder for fedora developers consisting of auto-generated emails describing upcoming changes to the operating system. Another 110 were long winded rants about the same operating system that went to a discussion folder (at least I bet they were long winded rants; I didn’t study most of them in detail). 102 were about my favorite linux-based TV recording software: MythTV. Another 120 E-Mails were messages that were most likely spam but placed in a folder for me to double check them because the spam-filtering software wasn’t confident enough to just throw them away without my help.

And so on. You don’t want more of a breakdown than that. Trust me.

Thank You For Waiting;

You’re Message Important To Us Me

That being said even my real INBOX occasionally turns into a black tar-pit where it seems I can never stay afloat. Even with only 10 messages going into it for a particular Wednesday I’m not perfect and frequently I “mean to respond later” but fail to get back to it in a timely manner.

The important thing is that the people that really matter (you) do end up in my highest priority folder (assuming you’re not one of those long-winded ranting folks). Everyone should filter their mail to put their most important email messages first in their lives and let the others stew until they’re nice as savory. I’m going to come back at some point in the not too distant future (I hope) to provide additional guidance for “getting ahead of your email”.

I’ve actually learned something from this long winded analysis too. So I’m glad I wrote it up. What I’ve learned is that I should have a severe headache and should step quietly away from the computer. So I think I will.