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.

Sunday, May 12, 2019

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
38.21.240.153 252628
113.113.120.152 18547
148.70.95.145 11529
150.138.92.17 11400
149.248.50.17 9917
123.129.223.133 9373
222.186.49.221 8689
39.105.122.74 8261
182.150.0.73 8098
47.107.64.105 7575
101.132.44.244 5745
170.33.8.193 5566
140.249.60.227 5520
61.160.207.99 5278
47.244.154.2 5084
23.107.43.194 5067
47.101.222.141 5066
47.101.169.118 5024
47.101.68.112 4449
47.102.135.146 4325
47.75.116.41 4200
47.244.36.42 4137
104.25.221.35 3638
144.48.125.176 3440
219.234.29.229 3402
125.88.186.186 3219
47.99.152.166 3167
39.108.51.161 3166
47.101.51.117 3161
210.83.80.21 3154
47.100.96.218 3139
47.101.200.97 3137
120.79.0.221 3090
47.100.183.18 2971
39.96.31.5 2944
47.98.38.120 2758
101.132.182.251 2756
47.107.123.238 2492
139.99.16.112 2290
47.101.157.245 2258
106.14.158.7 2226
47.100.234.2 2183
47.100.201.32 2090
120.79.40.9 2047
47.100.125.115 2037
101.132.37.45 1997
120.78.5.80 1985
47.101.68.50 1950
47.96.172.52 1915
20.188.110.231 1781
106.14.137.34 1118
119.188.250.37 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 38.21.240.153 is trying to attack something, or if it really just wants an up-to-date quotes file.

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-" …

RFC-822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES

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 Cu nningham's Law to kick into effect:

From
Daurnimator <XXXXX­XXXXX­XXXXX­XXXXX>
To
Lua mailing list <lua-l@lists.lua.org>
Subject
Re: Adding another way to point to "levels" to debug.getinfo and friends
Date
Mon, 13 May 2019 11:55:07 +1000

On Mon, 13 May 2019 at 09:03, Sean Conner <sean@conman.org> 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!

Monday, May 13, 2019

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.

Sigh.

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):

38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\001"
38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\001"
38.21.240.153:6951      "\001"
38.21.240.153:7333      "\001"
38.21.240.153:37152     "\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
38.21.240.153 10947 1508
38.21.240.153 11860 1425
38.21.240.153 14485 1420
38.21.240.153 65033 1418
38.21.240.153 4625 1409
38.21.240.153 4808 1401
38.21.240.153 37152 1400
38.21.240.153 65277 1394
38.21.240.153 27683 1389
38.21.240.153 17615 1389
38.21.240.153 48235 1388
38.21.240.153 27227 1386
38.21.240.153 14503 1386
38.21.240.153 43174 1385
38.21.240.153 43069 1377
38.21.240.153 47040 1372
38.21.240.153 6991 1370
38.21.240.153 18235 1369
38.21.240.153 57696 1360
38.21.240.153 7333 1233
38.21.240.153 6951 1204
38.21.240.153 36965 1171
38.21.240.153 16306 1139
47.99.152.166 47673 145
47.99.152.166 39606 144
47.96.172.52 48309 142
47.96.172.52 46769 142
47.107.64.105 59669 142
47.107.64.105 35763 142
47.107.64.105 22100 141
47.99.152.166 4302 140
47.107.64.105 53336 140
47.99.152.166 35758 138
47.96.172.52 44529 138
47.96.172.52 26878 138
47.107.64.105 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
74.82.47.61 2 May 03
185.94.111.1 4 May 04
74.82.47.37 1 May 04
74.82.47.17 1 May 05
71.6.233.171 1 May 06
74.82.47.29 1 May 06
104.152.52.39 1 May 07
74.82.47.57 2 May 07
74.82.47.33 1 May 08
206.189.86.188 1 May 10
74.82.47.49 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 104.152.52.39 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.

“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!

Friday, May 24, 2019

Notes on an overheard conversation at a doctor's office

“Take a seat right over there.”

“Okay.”

“Which arm?”

“It doesn't matter—it's hard either way.”

“Other phlebotomists have had problems finding a vein?”

“No, it's hard on me!”

“What?”

“I can't stand needles.”

“Oh, it's not going to hurt.”

“That's what they all say.”

“Now, now …”

“Aaaa­aaaaa­aaaaa­aaaaa­aaaaa­aaaaa­aaaaaa!”

“That was just the alcohol wipe!”

“You could have warned me!”

“Why me?”

“Aaaa­aaaaa­aaaaa­aaaaaa­aaaaaa­aaaaa­aaaaaaa!”

“I was just uncapping the syringe.”

“Oh god … ”

“Are we ready?”

“Errr­rrrrr­AAAA­AAAAAAA­AAAAAAA­AAAAAA­AAAAA­AAAA­AAAAA­AAAAAA!”

“You do realize we've soundproofed the room, so screaming won't help any.”

“How much longer?”

“Sigh.”

“How much longer? Aaa­aaaa­aaa! The horror! The horror!”

“Aaaaand—we're done! That wasn't so bad, was it?”

“The blade is sharp … Lucky … my heart only skips one beat …”

“What are you, twelve?”

“… blacked out … can't afford that …”

“Would you like a lollypop?”

“Please?”

Obligatory Picture

Trying to get into the festive mood this year

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

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: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

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-2024 by Sean Conner. All Rights Reserved.