Linux – OpenVPN –up script – “could not execute external program”

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.

In Nmap 6.46BETA6, the smb-check-vulns script was split into 6 different scripts:

• smb-vuln-conficker
• smb-vuln-cve2009-3103
• smb-vuln-ms06-025
• smb-vuln-ms07-029
• smb-vuln-regsvc-dos
• smb-vuln-ms08-067

You can run any specific checks you like, or all of them with --script smb-vuln-*, but be aware that many of these can cause a blue screen or other crash on the scanned system. Previously, these required you to add --script-args unsafe=1, so we added these scripts to the "dos" category so you can rule them out with --script "smb-vulns-* and not dos"