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:
| 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 <XXXXXXXXXXXXXXXXXXXX>
- 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!
