So I don’t know, are they doing, if it is supposed “white hat”
stuff, or whatever. It seems like that is an illegal intrusion. They
aren’t doing anything after they log in.
You are assuming Google themselves are “attacking” your server, when the reality is Google also provides web hosting and application hosting services to most anyone who pays to use them. So a user using those services could have a script/program in place that is doing the “hacking.”
Doing a reverse DNS record (PTR) lookup on 23.236.57.199
further confirms this idea:
199.57.236.23.bc.googleusercontent.com
You can check this—on your own—from the command line in Mac OS X or Linux like this:
dig -x 23.236.57.199 +nocomments +noquestion +noauthority +noadditional +nostats
And the result I get from the command line in Mac OS X 10.9.5 (Mavericks) is:
; <<>> DiG 9.8.3-P1 <<>> -x 23.236.57.199 +nocomments +noquestion +noauthority +noadditional +nostats
;; global options: +cmd
199.57.236.23.in-addr.arpa. 86400 IN PTR 199.57.236.23.bc.googleusercontent.com.
Or you could use just +short
to truly get only the core response answer like this:
dig -x 23.236.57.199 +short
Which would return:
199.57.236.23.bc.googleusercontent.com.
The base domain name of googleusercontent.com
clearly is what it says it is, “Google User Content” which is known to be connected to the Google App Engine “Platform as a Service” product. And that allows any user to create and deploy code in Python, Java, PHP & Go applications to their service.
If you feel these accesses are malicious, you can report suspected abuse to Google directly via this page. Be sure to include your raw log data so Google staff can see exactly what you are seeing.
Past any of that, this Stack Overflow answer explains how one can go about getting a list of IP addresses connected to the googleusercontent.com
domain name. Could be useful if you want to filter “Google User Content” accesses from other system accesses.
17
Take a look at this, specifically the comment: http://whois.domaintools.com/23.236.57.199
– Qantas 94 Heavy – 2015-03-22T01:14:37.8205If you properly secure the device this should not concern you. This actually is the answer to the question: What to do? Secure the device. – usr – 2015-03-22T12:44:33.977
1I rolled back the last edit because the focus is what to do if you know you are being attacked, rather than how to prevent it... which I think is documented lots of places... – Grady Player – 2015-03-23T16:55:58.757
I hope you're not using the
pi/raspberry
combination on anything else besides your honeypot. The moment you make it accessible from outside it should have something more decent than that. – None – 2015-03-24T13:39:24.727@mast pi is only honeypot; at some point I will just pull the logs, get a new IP and re-image it – Grady Player – 2015-03-24T13:58:24.407
@usr - of course it should concern you. While this isn't a full DoS, ~100k requests per day is still taxing for the server, and could easily push someone over the limit of their hostings bandwidth. – Davor – 2015-03-24T14:15:16.203
It does not answer your question "what to do" but it could give some context: there are services like https://www.shodan.io/ that do just that, they search for vulnerable services like the ones with default credentials and index them. They supposedly do nothing else, just index them. Maybe something similar happened to you.
– Bastian – 2015-11-19T16:32:13.947