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.
the rest of me 