> /index.php?s=index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 That is fine: networks are constantly scanned by bots. They are trying to hack any site using well-known vulnerabilities.
I have a lot of similar entries, although I do not have PHP on my site) I have never been hacked, but if I were, here is what I would do: * Reformat drive and install the latest stable version of your favorite OS. Be sure to upgrade it on the regular basis. Many OSes can do that using cron. * Use the latest stable version of some mature framework and also update it. If you aren't using one, then make sure you understand how to write secure code and how to run it correctly * Close all ports except http, https and ssh (which you should move away from 22 port because 22 port is also scanned by bots). Disable password authentication for ssh (use keys instead) * Check your server from the remote one to be sure all other ports are closed. * Configure lowatch (or something like that) to send your logs every day. Check logs carefully. On Wed, Oct 21, 2020 at 2:03 AM Rich Wales <ri...@richw.org> wrote: > On 2020-10-20 06:45, Wietse Venema wrote: > > > Extract time stamps for NON-ERROR web server responses, and > > correlate those time stamnps with activity in Postfix logs. > > Working on this now. There are log entries for several GET requests > asking for nonsensical things like the following: > > > /index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP > > > /index.php?s=index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 > > /index.php?m=admin&c=index&a=login&dosubmit=1 > > /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> > > A couple of the above are near the dates/times when I was having the > e-mail problem. But this could just as easily be a coincidence -- and > as far as I can tell, none of the above would accomplish anything -- the > supplied parameters are completely different from what the "index.php" > script in question is expecting. Are these strange GET requests still > something which I should investigate further? > > Some other observations (none apparently pointing to any problem): > > My server runs a web site which sells a book on shoemaking which my > mother wrote long ago. The site uses PHP, plus one JavaScript file. > There are, however, NO FORMS -- it's all done by clicking buttons, and > the financial transactions are handled by PayPal. Lots and lots of GETs > in the log for this site, but no PUTs or POSTs, and the files themselves > are all read-only, so I can't really see how they could have been > exploited (though I'm open to enlightenment on this). All of the above > weird GETs with random options tacked onto the URL were for this site. > And for what it may be worth, this site consists of raw PHP and JS which > I wrote from scratch, without using any frameworks or toolkits. > > Lots of attempts to GET a script named "wp-login.php" in several > directories. In fact, there are not (and never have been) ANY > "wp-login.php files on this server (not running WordPress). Strangely, > though, many of the GETs return a 200 HTTP status code -- not something > I would expect when a requested file doesn't exist. Were it not for the > 200 HTTP status code, I would have just dismissed these as irrelevant. > In any case, none of these "wp-login.php" attempts correspond to the > dates when I was having the e-mail problem. > > I had a couple of VERY old PHP scripts supporting "Project Honey Pot". > I've removed them, though, and will review my security before putting > them back (or, more properly, installing fresh scripts from the > project). The logs showed about 20 accesses to my honeypot scripts, but > none around the dates of interest. > > And I have still not seen any further instances of the hacker attack in > the last several days. > > Rich Wales > ri...@richw.org >
