So, I’m one of those people with a few credit cards: debit and credit accounts, personal and joint, plus business. Actually, eight of them. I only use two of them regularly…because eight is too much liability to walk around with.
The ones I use, I call “Personal” for regular use and “Business” for obvious reasons.
I also embrace modern technologies and use an iPhone and Apple Watch on which I’ve synchronized those cards with the Wallet app – plus Apple Pay. So that’s three accounts that are at my fingertips for easy use when they’re needed, without putting others at risk unless I intentionally take them out of the desk when needed.
Anyway, I’m shopping online the other day and notice that the proprietor has also added the option to use Apple Pay, so I click through.
After a bit of confusion about the shipping address and email address – they’re correct; still entirely unchanged, in fact, and I only clicked on Save – things processed just fine.
It wasn’t until a few hours later that I received an alert from one of my corporate card saying a purchase was approved. Hmm… I haven’t been on a trip recently… and that was meant to be on my personal card.
What’d I miss?
Turns out that with my state of somewhat unstable manual dexterity, I must’ve swiped on my Apple Watch, and switched to a different payment card.
Perhaps there will be an accessibility option for iOS/Watch/touch devices where we can tune the sensitivity of things like touch/drag/tap to accommodate those whose finger usage isn’t quite perfect.
Maybe some periodic validation of information with computer users when things don’t look quite right. We also need to find out why Apple Pay thinks “United States” doesn’t equal “United States”.
While I have been popping in from time to time, today was the official Back to Work day. A few conference calls and loads of emails later I think I’ll call it a day.
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.
In certain implementations of software monitoring solutions, the type, quantity, and frequency of monitoring – the system or service checks – can result in an increase in load on the systems being tested. This increased load can lead to the flawed interpretation that additional monitoring tools are necessary to identify the load factors, resulting in further-increased load.
Or, to summarize: throw so much monitoring at a platform that it unexpectedly increases load, which prompts additional monitoring. Repeat.
Or, to summarize the summary: You cannot observe any system without impacting it.
the rest of me 