The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Monday, May 13, 2019

“If you strike me down, I shall become more powerful than you can possibly imagine”

Of all the lightsaber duels in the Star Wars movies, the one in “Star Wars: Episode IV—A New Hope is probably the most sedate. But that's okay, because in 1977 this is the first time we're seeing freaking lightsabers! So cool! And it blew my 8-year old mind at the time.

But this reimagining of that fight? (link via Kirk Israel)

[Do you know just how painful it is to fall into a lava pit?  Do you?]

Had I seen that as an 8-year old, my head would have exploded!

They aren't attacking, they're being attacked

So that list of IP addresses I listed yesterday … it turns out they weren't the attackers, but the victims! And I was unwittingly helping to facilitate a DDoS amplification attack.


When we left off yesterday, I had modified my QOTD server to log the IP address, port number, and the incoming UDP packet to help figure out what the heck was going on. So pretty much off the bat, I'm seeing this (which goes on for nearly 4,000 entries):      "\001"      "\001"     "\001"      "\001"      "\001"     "\001"      "\001"      "\001"     "\001"

What had me puzzled are the ports—I wasn't familar with them. It may be that port 6951 deals with online transaction processing, port 7333 seems to have something to do with the Swiss Exchange, and nothing at all about port 37152. It's not exactly looking good, but the ports being attacked are rather all over the place (I'm only going to list two of the attacked IP addresses—there are more though):

Ports being attacked
host address port number requests
host address port number requests 10947 1508 11860 1425 14485 1420 65033 1418 4625 1409 4808 1401 37152 1400 65277 1394 27683 1389 17615 1389 48235 1388 27227 1386 14503 1386 43174 1385 43069 1377 47040 1372 6991 1370 18235 1369 57696 1360 7333 1233 6951 1204 36965 1171 16306 1139 47673 145 39606 144 48309 142 46769 142 59669 142 35763 142 22100 141 4302 140 53336 140 35758 138 44529 138 26878 138 52337 138

A lot of the ports are high values, which tend not to have defined services and are typically used for outbound requests to a service, like making a request to a QOTD service.

The data being sent is just a single byte, which is all that's really needed for the QOTD protocol to return a quote via UDP. So this looks like legitimate traffic, except for the volume.

But as I kept searching for “QOTD attacks” I kept coming across UDP amplification attacks (more of the same). It appears that the vast majority of traffic is forged (it's easy enough to forge UDP packets), and because QOTD sends more data than it receives, it's a rather cheap method to attack a target with a ton of traffic regardless of what the attacked machine is being used for (and my UDP based server probably isn't the only one unwittingly facilitating this attack).

A bit more research revealed a few servers that made a request (or a very small number of requests):

Requests to the UDP QOTD server
host address requests first request
host address requests first request 2 May 03 4 May 04 1 May 04 1 May 05 1 May 06 1 May 06 1 May 07 2 May 07 1 May 08 1 May 10 1 May 10

I'm guessing these machines made the query to see if my machine could be used for a UDP DDoS amplification attack, and would periodically check back to see if such attacks could continue from my server, which would explain the periodic nature of the deluge of traffic I saw (they weren't continuous but would happen in very random bursts). I also suspect there may be two different groups doing an attack, given the volume of traffic to certain targets.

It was also amusing to see attempt to spam me with email, and attempt to log in via ssh on the 7TH as well.

I've since disabled the UDP protocol on my QOTD server. Sigh. This is why we can't have nice things on the Intarwebs.

Sunday, May 12, 2019

Experimental headers are no longer experimental

On the Lua Users email list the topic of custom email headers came up. Back in the early days, RFC-822 stated that:

Any field which is defined in a document published as a formal extension to this specification; none will have names beginning with the string "X-" …


This also applies to headers starting with “x-” as Internet based text headers are case-insensitive.

Now given that RFC-822 has been obsoleted by RFC-2822 and RFC-5233 I thought I would check those out as well:

Fields may appear in messages that are otherwise unspecified in this document. They MUST conform to the syntax of an optional-field. This is a field name, made up of the printable US-ASCII characters except SP and colon, followed by a colon, followed by any text that conforms to the unstructured syntax.

The field names of any optional field MUST NOT be identical to any field name specified elsewhere in this document.

RFC-5322: Internet Message Format

Hmm … nothing about “X-”. I replied that starting a non-standard header with “X-” was still a safe way to go, only for Cunningham's Law to kick into effect:

Lua mailing list <>
Re: Adding another way to point to "levels" to debug.getinfo and friends
Mon, 13 May 2019 11:55:07 +1000

On Mon, 13 May 2019 at 09:03, Sean Conner <> wrote:

In other RFC documents (too many to mention) private or experimental fields are usually labeled with "X-" (or "x-") so your best bet is to create a header name starting with "X-" to be safe.

Please stop using the X- prefix! See RFC 6648:

This document generalizes from the experience of the email and SIP communities by doing the following:

1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].

Interesting. The “X-” standard for non-standard headers was to allow for experimentation without fear of conflicting with other headers, but the process of converting such headers to a standard header prove problematic. But RFC-6648 does cover the case when one doesn't want to standardize a header (or parameter):

… In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122].

RFC-6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

What a wild idea!

I wonder what they think they're attacking?

In addition to a self written gopher server I also have a QOTD server accepting requests via TCP and UDP. I never mentioned it as I just put it out there to really see what would happen. I will occasionally see a request go by, but over the past two weeks, some people have really been hitting it hard via UDP:

Requests to the UDP QOTD server (over 1000 requests)
host address requests
host address requests 252628 18547 11529 11400 9917 9373 8689 8261 8098 7575 5745 5566 5520 5278 5084 5067 5066 5024 4449 4325 4200 4137 3638 3440 3402 3219 3167 3166 3161 3154 3139 3137 3090 2971 2944 2758 2756 2492 2290 2258 2226 2183 2090 2047 2037 1997 1985 1950 1915 1781 1118 1095

There doesn't see to be much I can find about this, other than a potential link to XBox Live, but that doesn't seem right. It's hard to say. So to see what might be happening, I modified the QOTD program to record anything it receives via UDP. That way, I should be able to figure out if is trying to attack something, or if it really just wants an up-to-date quotes file.

Wednesday, April 24, 2019

Just one of life's smaller mysteries

Some fellow cow-orkers and I were returning from lunch to work and as we rounded the corner to The Ft. Lauderdale Office of The Corporation, we found the entire front of the building swarming with fire and rescue vehicles. Thirteen in all.

There were no police, so it wasn't an office shooting (thankfully!). No crowd of people were huddled outside the building, so there didn't appear to be an evacuation. No smoke, so there apparently was no fire. But something happened that required thirteen responding units.

[You can easily make out four firetrucks, one of which was in the process of transforming to a giant robot.] [Another four, although one is hidden somewhat by the trees.  There are more, but you can't see the trucks for the trees.]

We were able to park and enter the building. From what little we heard, there was an “incident” on the 6th floor, but what it was, and how many were involved, was unknown.

Just one of life's smaller mysteries.

Tuesday, April 23, 2019

Dealing with phone numbers

Project: Wolowizard only supports NANP numbers, but since those numbers come via The Protocol Stack From Hell clearly marked as NANP, it's easy to determine there if a number is NANP or not. It's not quite as simple in “Project: Sippy-Cup” since SIP is … a bit loose with the data formatting.

There, the numbers are formatted as a tel: URI (or a sip: URI but the differences are minor). If the number is “global,” it's easy to determine a NANP number because it will be marked with a “+1” (“1” being the country code for North America). So, tel:+1-501-555-1212 is most definitely a NANP number, while tel:+501-555-1212 is not.

Things get a bit more muddy when we receive a so-called “local” number. RFC-3966 clearly states that a “local” tel: URI MUST (as defined in RFC-2119) contain a phone-context attribute—except when it doesn't (I swear—the RFC contradicts itself on that point; tel:8005551212 is valid, even though it's a “local” number and missing a phone-context attribute because it's a “national freephone number”). So tel:555-1212;phone-context=+1501 is NANP, while tel:555-1212;phone-context=+501 is not (look closely at the two—one has a country code of “1” while the other has a country code of “501”). It's worse though, because while tel:555-1212;phone-context=+1501 is NANP, you cannot use the phone-context attribute to reconstruct a global number (the RFC contains the following example: tel:863-1234;phone-context=+1-914-555—um … yeah).

To further complicate things, the phone-context attribute does not have to contain digits—it can be a domain name. So tel:555-1212; is a valid number. Is it NANP? International? Who knows?

So what does “Project: Sippy-Cup” do? If it receives a “local” number with a “+1” country code in the phone-context attribute, it's marked as NANP; any other country code is it marked as non-NANP. If the phone-context attribute contains a domain name, it is treated as a NANP number (based on what I saw in production). And if there's a missing phone-context attribute for a “local” number, “Project: Sippy-Cup” treats it as a NANP number if it has at least 10 digits.

Now, why do I care about this? Because we want to avoid doing an expensive database query for non-NANP and invalid NANP numbers, but “Project: Heimdall” wants all the numbers for tracking potentially fraudulent calls.

The feeling when your new task is already done

“The ‘Project: Heimdall’ team now want all the numbers,” said TS1, my fellow cow-orker.

“Really?” I asked. “They can finally deal with international phone numbers?”

“Apparently yes. So ‘Project: Sippy-Cup’ needs to open the flood gates and let all the numbers through. But make it configurable.”


So I dive into the code for “Project: Sippy-Cup” and … what's this? The code is already in place. From last year. When it was clear that “Project: Heimdall” could not, in fact, handle all the numbers! I remember it was annoying having to send all NANP numbers (those that are 10 digits, like “501-555-1212”), even the malformed, invalid NANP numbers (like “501-511-1212”), while making sure I didn't pass along valid, international numbers that also happened to be 10 digits long (like “501-555-1212”). Now that the “Project: Heimdall” team has to deal with the crap we get … well … good luck. We're all counting on you.

Monday, April 22, 2019

“Can you tell me how to get? How to get to Westeros?”

I have a few friends that are into “The Game of Thrones” (and if not the TV series, then at least the book series). For them, I have two videos: the first is “Game of Chairs,” a Sesame Street parody of the TV show. The second video is … well … a meeting between Cersei and Tyrion that is interrupted by an unexpected guest. To say more would be to spoil it.

Thursday, April 18, 2019

“Help! I'm still trapped in a Chinese fortune cookie factory!”

Bunny and I are having dinner at a Chinese restaurant. The check is delivered and we crack open our fortune cookies. Mine is something generic, but Bunny's cookie says, as God is my witness:

[“Pick another fortune cookie?”  I guess that's a great way of increasing sales.]

Unfortunately, there was no other fortune cookie to pick from. Go figure.

Monday, April 15, 2019

I like the whole “computers-in-wood” asthetic

Love Hultèn (or Hultén—it's spelled both ways on that page) made a series of life sized computers based off the old Lego computer bricks (link via Jason Kottke) and I must admit, they are very cool!

But then I checked out Love's other projects and the The Golden Apple—wow! A Mac Mini housed in a custom walnet case based off the original Macintosh 128K case is just beautiful (although to be truthful, I could do without the gold keys on the keyboard but that's me). The Pet De Lux is no slouch either.

One of these days, I'll get a computer into a wood case. One of these days …

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2019 by Sean Conner. All Rights Reserved.