As Fiasco Labs points out in their answer, these type of log entries are a dime-a-dozen. But as a systems administrator with a deep history managing and protection LAMP-based web servers, this is not an attack as much a scripted “probe” of your system by someone somewhere. These probes/scans of a system are done to see what—if any—servers out there are vulnerable; not just your servers. In general this is the equivalent of the “war dialing” that was fairly commonplace in the 1980s/1990s days of system hacking via acoustic modem; scan a list of systems, see what systems have “flaws” and then see what you can do with those supposed flaws.
Should you be panicked about this? Not at all. Any and every web server on the Internet is being constantly probed. I manage a few Ubuntu Linux web servers and I am 100% positive if I were to check my logs right now, tomorrow, a day from now, etc… I would see entries similar to what you are seeing. But I am not losing sleep over this at all. The reality is if your core OS is properly patched and the framework you are using is patched and up to date, you are in good shape.
Using a tool like Fail2Ban is not a bad idea, but I consider it a bit of overkill if you ask me. The reason being that even with a tool like Fail2Ban or even ModSecurity, a clever bot might still get through. Which is why my best advice to any systems administrator is to harden their servers and have a way to easily recover from a systems compromise.
Harden Your Server and Your Codebase
What I consider best security practice is hardening you LAMP server setup and ensuring our PHP code is solid. This answer on the security Stack Exchange site is a good starting point in understanding what “hardening” means, but honestly if you are not a systems administrator much of this might be over your head.
So I would recommend that unless you are truly up to the task of learning how to be a Linux systems administrator, you might be better off using some shared hosting provider somewhere. That way their admins use their skills to worry about this stuff and you can concentrate on running/coding the website.
That said, even with a shared hosting setup, you are not off of the hook. Even if you are using a well-regarding PHP framework, you need to stay on top of patching that PHP framework pretty much whenever an update is released. And as far as your core code base, you should be sure to not cut corners on basic security practice in how you code. You basically should learn how to sanitize any/all input your site receives and how to properly setup the site so even if it fails, it doesn’t do so in a way that is a disaster.
Backups and Disaster Recovery
And in my mind that means backups, backups, backups as well as more backups. You can never control server compromise, but data/system recovery is always in your control. Which all means you need to have some kind of small-scale “disaster recovery plan” in place to restore your site.
Which means, be sure to backup your core codebase so if it is ever compromised, you can easily redeploy clean code without much effort. To that end I would highly recommend you use a source code management tool like git
for your version tracking as well as setting up a GitHub repository for remote storage. Also, learn how to use Capistrano with PHP to deploy code; I have an answer that addresses how to do this over here.
Ditto with your MySQL database; depending on size/scale have backups available. I like to have MySQL backups on small-to-medium sized sites run every 3-4 hours. That way the worst that might happen if a site is hacked is the database is at the most 3-4 hours stale; a stale database within the same day is better than a wrecked database with no backup at all.
Best Answer
Another possible way to structure this code in a way that won't trigger this race condition is to group the rest of the code inside a
{ ... }
block and pipe that totee
.That way, bash will be guaranteed to
wait()
fortee
to complete before ending the script.