I started noticing these in my ingress logs recently:

2017/08/18 20:14:51 [error] 27277#27277: *174208140 open() "/usr/share/nginx/html/YesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScann" failed (36: File name too long), client: 137.226.113.11, server: , request: "GET /YesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreScanningForResearchPurposePleaseHaveALookAtTheUserAgentTHXYesThisIsAReallyLongRequestURLbutWeAreDoingItOnPurposeWeAreSca

They seem to have started 09 Aug. I’m getting them in short bursts – six requests in rapid succession. Then another burst a few hours later. Then a day or so later, several more.

Alas, our logging doesn’t capture the whole record, so I can’t see the user-agent as the message suggests. But I can see a client IP address: 137.226.113.11

There’s nothing interesting straight away at that IP. It is hosting a web service, but its default doc is a 404 at the moment: http://137.226.113.11.

But what else is there? A trace shows it’s in Germany and likely resolves to something owned by rwth-aachen.de:

$ traceroute 137.226.113.11
    traceroute to 137.226.113.11 (137.226.113.11), 64 hops max, 52 byte packets
     1  rac1.esthermofet.net (192.168.1.1)  3.624 ms  0.777 ms  0.627 ms
     2  63.140.19.1.ifibertv.com (63.140.19.1)  2.557 ms  2.568 ms  3.746 ms
     3  208.84.220.193.ifibertv.com (208.84.220.193)  2.446 ms  2.576 ms  2.462 ms
     4  174.127.154.33 (174.127.154.33)  8.541 ms  8.791 ms  8.765 ms
     5  ae9.mpr1.sea1.us.above.net (208.185.155.61)  8.415 ms  8.326 ms  8.561 ms
     6  ae27.cs1.sea1.us.eth.zayo.com (64.125.29.0)  149.309 ms  141.520 ms  141.475 ms
     7  ae2.cs1.ord2.us.eth.zayo.com (64.125.29.27)  142.018 ms  153.854 ms  141.519 ms
     8  ae3.cs1.lga5.us.eth.zayo.com (64.125.29.208)  158.628 ms  141.480 ms  148.802 ms
     9  ae5.cs1.lhr11.uk.eth.zayo.com (64.125.29.127)  141.373 ms  141.690 ms  141.361 ms
    10  ae6.cs1.ams10.nl.eth.zayo.com (64.125.29.76)  141.582 ms  141.623 ms  144.583 ms
    11  ae0.cs1.ams17.nl.eth.zayo.com (64.125.29.81)  141.803 ms  141.407 ms  141.834 ms
    12  ae2.cs1.fra6.de.eth.zayo.com (64.125.29.58)  142.005 ms  141.638 ms  141.478 ms
    13  ae27.mpr1.fra3.de.zip.zayo.com (64.125.31.217)  141.756 ms  141.556 ms  141.549 ms
    14  ae8.mpr1.fra4.de.zip.zayo.com (64.125.26.234)  141.561 ms  141.473 ms  141.273 ms
    15  * * *
    16  kr-aah15-0.x-win.dfn.de (188.1.242.110)  177.355 ms  177.996 ms  177.197 ms
    17  fw-xwin-2-vl106.noc.rwth-aachen.de (134.130.3.230)  170.592 ms  171.043 ms  170.466 ms
    18  n7k-ww10-1-vl158.noc.rwth-aachen.de (134.130.3.243)  174.294 ms  174.368 ms  174.157 ms
    19  n7k-ww10-3-po1.noc.rwth-aachen.de (134.130.9.166)  174.397 ms  174.189 ms  175.918 ms
    20  c4k-i4-1.noc.rwth-aachen.de (137.226.35.67)  172.026 ms  171.764 ms  173.803 ms
    21  researchscan4.comsys.rwth-aachen.de (137.226.113.11)  173.819 ms  173.620 ms  173.683 ms

Okay, the penultimate stop also resolves to rwth-aachen.de, so I think a full port scan of that host’s segment might reveal some useful details, but let’s just scan this one host and see what we get:

# nmap 137.226.113.11

Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-19 00:56 UTC
Nmap scan report for researchscan4.comsys.rwth-aachen.de (137.226.113.11)
Host is up (0.13s latency).
Not shown: 994 closed ports
PORT     STATE    SERVICE
80/tcp   open     http
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
1433/tcp filtered ms-sql-s
2323/tcp filtered 3d-nfsd

Nmap done: 1 IP address (1 host up) scanned in 23.45 seconds

An MS host, eh? With MS SQL exposed to the internet? Looks like there might be some shenanigans going on there.

Let’s scan their whole segment. Maybe there’s something else with port 80 open that we can casually observe:

# nmap 137.226.113.0-255 -p80 --open

    Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-19 01:03 UTC
    Nmap scan report for jodelforschung.comsys.rwth-aachen.de (137.226.113.6)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan1.comsys.rwth-aachen.de (137.226.113.8)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan2.comsys.rwth-aachen.de (137.226.113.9)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan3.comsys.rwth-aachen.de (137.226.113.10)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan4.comsys.rwth-aachen.de (137.226.113.11)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan5.comsys.rwth-aachen.de (137.226.113.12)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan6.comsys.rwth-aachen.de (137.226.113.13)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan7.comsys.rwth-aachen.de (137.226.113.14)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan8.comsys.rwth-aachen.de (137.226.113.15)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan9.comsys.rwth-aachen.de (137.226.113.16)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan10.comsys.rwth-aachen.de (137.226.113.17)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan11.comsys.rwth-aachen.de (137.226.113.18)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan12.comsys.rwth-aachen.de (137.226.113.19)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for vega.comsys.rwth-aachen.de (137.226.113.26)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan19.comsys.rwth-aachen.de (137.226.113.27)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap scan report for researchscan20.comsys.rwth-aachen.de (137.226.113.28)
    Host is up (0.13s latency).
    PORT   STATE SERVICE
    80/tcp open  http

    Nmap done: 256 IP addresses (243 hosts up) scanned in 10.17 seconds

Wow. Okay, let’s just ask those for their default pages and see what comes back.

nmap 137.226.113.0-255 -p80 -oG outfile
for i in `cat outfile | grep -i open | awk ‘{print $2}’
do
echo $i
curl http://${i}
done

That produced loads of output, but it did come back with this:

Ah, a research project!

I’m afraid their reasoning is a bit vague. “…helps computer scientists study the deployment and configuration of network protocols and security technologies…”

You don’t have to be a computer scientist to understand that sending abnormally long requests to sites will result in an error.

For us, this isn’t causing any sort of problem – it’s really just a minor mystery I noticed in the logs while researching something else entirely.

For now, I’m going to leave our firewall unchanged. But I’m also going to log and chart their probes to see if the behavior changes over time.

I’ll do my own research project.