Is it possible that they were able to download your server side script? is that directory open in such a way to allow them access to download rather then execute? does the script leak those parameters when executed? here is what i do for similar situations: 1. enable https: it really does not hurt and this should just be on by default. 2. use an api string or use a custom user agent string: only clients with the correct string will actually be listened to (this will help you in the future too) 3. enable http auth: even if it is stupid data; it keeps away those random rubbernecker and crawlers that ignore robots.txt, you can even use REMOTE_USER as additional metadata that can be used to track down systems. On Thu, Nov 17, 2016 at 1:52 PM, Loren Burlingame <theixian at hotmail.com> wrote: > Here is the scenario: > > > I have written a simple little Perl script which runs on an Linux web host. > > > The purpose is to track the IP of laptop computers we own. > > > The laptops are Windows 10. They run a little PowerShell script triggered > off of an event (when an IP address is assigned to an interface). > > > The computer name along with a couple of parameters is encoded in base64 and > this string is passed in the URL to the Perl script on the server over > unencrypted HTTP. > > > The base64 encoding is in no way an attempt to encrypt or "secure" the > communication, it is just a convenient way to get all of the parameters into > a single HTTP GET parameter. > > > The server-side Perl script is set up in such a way that if any query that > isn't recognized is received, an error page is displayed. > > > Only strictly sanitized input is then inserted into an SQLite db file. So > the parameters have to be perfectly ordered and then encoded then received, > decoded, checked and then finally inserted. > > > Here is the confounding part: > > > Twice now, in as many days, I have seen a duplicate of a query for two of > our laptops come in from unexpected IPs and written to the db file. > > > The laptops in question are sitting in our office, have not been touched by > users and have no correlating events in their logs. > > > The querying IPs are only a few octets apart (65.208.151.114 and > 65.208.151.119) and both show that they belong to a block of IPs owned by > Kintiskton LLC (a subnet of a Verizon Business block). Both IPs geo-locate > to La Hara, California (a suburb of Los Angeles). They also are using a > strange UA: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" > > > I found these pages when searching for Kintiskton: > > > http://www.guyellisrocks.com/2012/01/kintiskton-llc-ip-ranges.html > > https://ceph.algia.co.uk/wp/kintiskton-or-the-story-of-the-copyright-vigilantes/ > > > So this would appear to be a web spider of some kind which, according to > some, is poorly written, extremely aggressive and ignores robots.txt. > > > I get that the site will be crawled and it doesn't surprise me that this was > within an hour or so of it first going up. > > > What I don't understand is how an entity out on the net is able to, > apparently, know the full URLs including queries and parameters of a site > which I just put up and only just queried myself? > > > Anyone up for schooling me on this new fangled Internet thing? > > > --Loren > > > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >