Simple enough if you don’t mind editing a file and changing some perms.

1. First you need to make sure that the wp-content(and plugins and themes) directories are owned by your apache process.. in FreeBSD it’s httpd in linux it’s www-data
2. Next you should chmod the wp-content, plugins and themes directory to 755.  For some reason WP hates things at 777
3. Lastly you need to add this little line of code to the bottom of your wp-config.php file: define(‘FS_METHOD’, ‘direct’);

Hope that helps

But in the words of Lavar Burton: Don’t take my word for it, check it out for yourself HERE

Some samples of their themes

In the end I found that it was being called from the footer.php page and it wasn’t the only thing being called.. An entire subpage was being pasted on the bottom of my blog:

Internet Marketing Reviews by Jayson Hahn is what it was called and the theme was called ‘Life Cycle 1.00 by themepriview’

So if yuo’ve gotten this, change your theme and the problem will go away

Soo, I was uploading a large file to my CMS through drupal and at about 35%(of a 40MB file) I would get booted to an error page with the following message.  I looked high and low and while I found a solution that told me to go into mysql and set the wait_timeout like this: “set wait_timeout = 28800″ (for some reason my host had it set to 45) it was still occurring.

The other thing was to put this: mysqli.reconnect = On in my php.ini file which didn’t work but then I tried this isntead: mysql.reconnect = On and I’m not 100% sure if that was what did it but the last thing I did was I bypassed my router and plugged the cable modem into the laptop directly and guess what?  Bloody file went through..

2 hours later I get my life back

Funny enough now I’v

56MB of virtual memory and 40MB of resident memory usage

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
55392 www 1 106 0 56460K 39664K CPU2 2 15:43 50.49% httpd

Follow that up with what is probably a pretty stock linux server running apache 2.2.

98MB or virtual memory usage and 73MB of resident.

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
7546 nobody 15 0 98648 73m 2040 S 0.7 1.0 0:00.53 httpd

That’s nearly HALF the memory usage for 2 servers doing exactly the same thing running exactly the same software minus the OS.  See kids, it pays to play with your httpd.conf  The irony of course is that the tuned server has 2GB of ram and the stock server has 16GB.  Oh well

Search the blog for tuning tips but one of the key things is knowing what every apache module does and ditching absolutely every single one you don’t absolutely need.  Trim the fat off apache and then you can work on tuning the actual settings in apache.

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

The big problem arises now because I have 60 blogs all with 10′s of thousands of posts being accessed by 100′s and 1000′s of people every day, clearly this isn’t somethign wordpress was built for but I have a flavoured history of bending software to my will.  My CPU usage was constantly at 100% and it’s only recently that I’ve gotten around to fixing this, or so the germans would have me believe  Here’s what you need to do

1. Make sure eAccelerator is installed on your server
2. Tweak your apache settings.. Right now this is what I have my httpd.conf set to:

3. MaxKeepAliveRequests 20
   KeepAliveTimeout 2
   Timeout 45
   MaxClients 20
   MinSpareServers 2
   MaxSpareServers 7
   StartServers  4

4. Make sure that you have wp-super-cache installed.. I researched the crap out of caching plugins and this one consistently came out on top
• Now here’s the kicker..  I had a script that installs and sets up new websites for me and much to my chagrin after 6 months I just noticed that none of my blogs were caching properly.. the reason was because wordpress didn’t have write access to wp-content/cache/supercache.  Make SURE the wp-content/cache directory and ALL subdirs are writable by apache
5. Increase your expiry time substantially.  The default is 3600 seconds(1/2 hour) but why do I want all of my sites rebuilding their cached pages every 30 minutes when I only update the sites every 4 hours?  So change the expiry time to something more in line with the frequency of your updates so you’re server isn’t constantly rebuilding pages all the time
6. Preload, preload preload: This one was huge for me because of the number of posts I have.  Go into the preload section and turn on preload mode.  After you’ve updated the settings click on preload cache now.  This will systematically go through and precache your entire website..  The beauty about preload mode is that the precached posts done here never expire or are ever recached.  The preloading processes is fairly slow so you can do a few sites at a time without worrying that it’s going to melt your server into the ground
7. WP-Minify: This wonderful little plugin takes your CSS and JS files and compresses the hell out of them, as much as it can without breaking them so that instead of your people having to load 10 50k CSS files it crunches it down to 1 50k  CSS file or something ridiculous like that.  Definitely some tweaking to look at with that
8. Remove all unnecessary plugins: The less that loads the less your load. Figure out what you absolutely don’t need and scrap it
9. Disable all Apache logging:  In total I have a few hundred websites on the server and recently I’ve turned off all domain specific apache logging.  If I need to trouble shoot a domain I’ll just re-enable it and the repeat the problem to see what’s going on but disabling this has also reduced my cpu consumption by leaps and bounds.
10. Nginx: Whatever you do don’t have all of your traffic flowing solely through apache, get something like nginx on there.

I’ve never seen high CPU usage from mysql with any of my blogs so I’ve given up trying to optimize that..I’ve gone through the process of trying to optimize mysql but never noticed a difference so I just leave that as stock.  Hopefully that helps you out, my server isn’t the flashiest or the beefiest of girls but she’s a well oiled and highly tuned machine.  With these tweaks I should be able to get a few more years out of the ole girl yet

1. You have no posts(ie: you even deleted the default post wordpress comes with
2. In the ‘Reading Settings’ you’ve changed the front page from ‘display latest posts’ to ‘A Static Page (select below)
• The key with the above problme is that you failed to read the (select below) portion and if you look at ‘Front Page’ the drop down box probably has –Select– selected, which means nothing is selected.. Pick a god damn page and you’re off the the races!

Well what a delight that I checked on one of my old unused sites to find malware warnings and it redirecting me to http://placecollocation.ru/ .  This of course made me look a little closer as it’s folly to assume a breach is contained to one little area and sure enough I found wordpress and drupal sites alike redirecting.  So being the good server admin I cleaned it out only to wake up the next morning with one of my users telling me that the server was hacked and then pointing me to this very page saying ‘here’s how to fix it ’, obviously he doesn’t know this is my blog but I had to lasugh

So after a few hours of scripting I’ve cleaned it all out again but I wanted to post up a little help for those going through the same thing.

First off a big thanks goes out to Hack Sparrow for this post: http://www.hacksparrow.com/wordpress-hacked-getting-forwarded-to-distributioncorporate-ru-solution.html  as that pointed me in the right direction immediately.  Although if I could be a little critical of our hacking/flying/chirping friend I would say you shuold have looked more closely at those backdoors.. Obviously they could go by many names so you need to be able to find them if their location or name changes.

So first step: Make a list of all infected .htaccess file

• Go find one that know is infected, it will contain a whole lot of ^M or linebreaks in it and then show you some nice little code that redirects your users to some russian site.  The 3 I’ve heard of are placecollocation.ru , flyghtairline.ru or distributioncorporate.ru.  Copy that url
• Go to your home root directory, or /usr/www  or whatever your webroot dir is and run: find . -name .htaccess -exec grep -H {RUSSIANDOMAIN GOES HERE} > infected.txt
• Clean out all the undeeded data in that file so it’s just a list of files:
• In linux: sed -i ‘s/:.*//g’ infected.txt
• In BSD: sed -i ” -e ‘s/:.*//g’ infected.txt
• Clean out duplicate listings: uniq infected.txt > infected.new && mv infected.new infected.txt

Second Step: Clean the infected files

• Lucky for us this guy announces himself by putting a shitload of linebreaks which awk can easily recognize.. What we want to do is tell awk to look for two of these line after line and delete everything below their occurence, output that to a new htaccess and then copy that over the infected one.  *It wouldn’t hurt to back up your .htaccess files*
• Run: awk ‘p $0 == “\r\r”{exit} $0 != “\r”{print $0}{p=$0}’ .htaccess > htaccess && mv htaccess .htaccess for each of the .htaccess files in your infected or alternatively just write a script that reads that file line by line, going through and performing the above command

Step 3: Finding the Backdoors

• As a good sneaky fucking russian this guy leaves backdoors so that he can re-infect you hours after cleaning this out in the form of the following files: _wp_cache.php sm3.php or wp.php.  If you look at these files you'll see they start with something like this:

• <?php # Web Shell by oRb
$auth_pass = "";
$color = "#df5";
$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'Windows-1251'
• So the prudent thing to do would be to scan all .php files(or all files in general if yuo were really wanting to be careful) and search for smoething unique about this file, ie: Windows-1251 or Web Shell by oRb like so:  find . -name “*.php” -exec grep -H ‘Web Shell by oRb’ ;\ -exec rm {} \;

Final Step: Upgrade all outdated timthumb files

• This whole mess was caused by an exploit in timthumbs, which goes by thumbs.php or timthumbs.php.  It’s very important to realize though that there could likely be other, non timthumbs files on yuor server called thumbs.php as it’s a pretty ambigious filename.  So you need to find all of your timthumb files and replace them with updated ones
• So let’s grab the updated timthumb: wget http://timthumb.googlecode.com/svn/trunk/timthumb.php
• find . -name “*thumb*.php”  -exec grep -H timthumb {} \; -exec cp timthumb.php {}

And that’s that!  You should be all good to go..
PS – One last thing I did was to chown root all of my .htaccess files and leave them chmodded to 444.  Make sure this doesn’t screw anything up on your end but hopefully it should prevent them from being overwritten in the future

So I went googling around to find a good way to monitor login activity and ban IP’s for people who have more than 7 failed logins.  I should note here that the best bet would be to have an IP whitelist that only allows ssh connections from specified IP’s but I’m jumping all over the place so often that that’s a bit of a pain in the ass, which leads me to the following solution found herE:

http://www.freebsdwiki.net/index.php/Block_repeated_illegal_or_failed_SSH_logins

First thing to do is setup some precautionary measures with sshd:

Limiting SSH login sessions

In your sshd_config file the following settings can also help slow down such attacks.

• LoginGraceTime

The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 120 seconds.

• MaxStartups

Specifies the maximum number of concurrent unauthenticated connections to the sshd daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10. Alternatively, random early drop can be enabled by specifying the three colon separated values “start:rate:full” (e.g.,”10:30:60″). sshd will refuse connection attempts with a probability of “rate/100″ (30%) if there are currently “start” (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full”

Next you want to make sure your log files are up to snuff and then setup a real basic script that scans those files(via a cron) and blocks IP’s based on the results.  I find IPFW invaluable for the work I do, so that’s the route I’m going but if you use PF or IPF there are instructions in the link above for them.

/etc/syslog.conf

You need an auth.* line in your syslog.conf file in order to log all authentications.

auth.*                                          /var/log/auth.log

Using IPFW

Create sshd-fwscan.sh and put it somewhere handy like /usr/local/sbin/

#!/bin/sh
if ipfw show | awk '{print $1}' | grep -q 20000 ; then
        ipfw delete 20000
fi
# This catches repeated attempts for both legal and illegal users
# No check for duplicate entries is performed, since the rule
# has been deleted.
awk '/sshd/ && (/Invalid user/ || /authentication error/) {try[$(NF)]++}
END {for (h in try) if (try[h] > 5) print h}' /var/log/auth.log |
while read ip
do
        ipfw -q add 20000 deny tcp from $ip to any in
done

Note: To make sure IP’s expire we delete and add rule 20000 of the firewall each time, thus if the IP’s are no longer duplicates in the auth.log they are no longer firewalled.

 

That’s that, I just ran the script as a test and viola, I’ve got 3 new rules in IPFW blocking those IP’s.. hoorah!