WELCOME!

Restoring the whole site to a working state from an online site to a testing server, or from a testing server to an online site is a bit trickier. One has to account for differences in the server configurations. This leads to the locking of certain files on both the testing server and online server so that accidental updating doesn't occur. These files are usually the CMS configuration file, and .htaccess in the document root.

Hence in the following script, areas are left out that would be too specific to certain installations to be generically useful.

full_site_restore.sh

The CMS database is the heart of any content management system. It's loss or damage will result in the loss and or damage of all of your hard work, and that of your commentators, posters, and contributors. Below, are two scripts that complement each other, one backs up the database into a SQL file, the other restores it from a SQL file.

This script also allows porting between a testing server and the on-line site. In the script is a test for a folder called testing.server, discussed in the first page of this series, which differentiates between the server on-line and the testing server.

backup_db.sh

Unusually so, actually. Some of the methods may be working. Attack vectors cycle through periodically, some brute forcing the root, some brute forcing non-existent accounts. I still haven't figured out how to trap the password strings coming in on the brute forcing. Majority of attacks last week from CN, then US.

The activity has changed to the on-line servers, where I occasionally get DOS attacks. The GoDaddy servers throttle down if they sense one going on, but sometimes mistake valid activity for a DOS attack. All that takes latency to a 3-7 second level, which is OK as long as it stays on the lower end.

A new tool that I'm learning is Metasploit. An excellent penetration testing tool, but with a fairly steep learning curve. Maybe one of these days I'll make enough money to buy the pro version…

Attacks have ceased pretty much on the testing server, but I must have pissed somebody off last night. WOOT!

DDOS attacks started in the late evening, starting probably around 21:00 through at least probably midnight. Can't actually tell because I can't access the httpd logs. The positive note is this lead to me asking GoDaddy where the httpd logs are, something I wasn't aware of (in FTP Manager). Bluehost allow access to the server logs, but Yahoo did not when I used them. It's a virtual machine so the logs don't compromize any hosting provider confidential data...

The offending IP addresses were:

• 91.121.170.124 - FR, I know the bot-net there, and they have been getting inverse “Pavolovian Dog” training. I am almost willing to bet the control node resides in this general IP area,