Boby:

Some hints and tips on security issues.

• 1) Passwords: Use strong passwords! Never share your password or keep them in unsafe place. Give passwords to everything you can, phpLD admin, database user, FTP access, everything.
  To have a strong password, try to include some special characters like “$”, “@”, “&”, “=”, “+” or whatever else you want. Also use both lower- and uppercase characters. You password should not be shorter than 6 characters.
  
• 2) Backups: Only people who had once a really big problem because they did not backed up know what I am talking about. Make backups as often as you can, backup all your files each time you make a small change, backup also your database.
  
• 3) Permissions: Give only really needed permissions to files/folder. Unless the server is running as user “nobody” or simmilar, try to give files/folders the same username as the webserver is running. Do not use 666 or 777 permissions unless the script (.php) needs it. Usually it’s good to run files/folders with permission set to 664 but also 755 or 775 is good.
  If you are a security freak I can let you know that a regular script (.php) can run with permission set to 004 (others may read) if file owner is not the same like webserver user, if files/folders run under same user like the webserver you can give 400.
  After an installation/upgrade, change file permission of your “include/config.php” file. Revoke writing permissions!
  For phpLD-v3.0+ users, you can revoke writing permissions to sitemap and backup files too after you create them.
  
• 4) Files and Folders Protection: If your host supports “.htaccess” files you can easily protect some files and folders.
  After a discussion in the phpLD3 supporters forum, we have found some good ways to protect template files (.tpl). First you can create an “index.php” file in your “templates” folder 
• 5) Unneeded Files: Most *NIX (Linux, *BSD) create by default file backups each time you modify something. This files are marked eighter as “~filename.ext” or “filename.ext~” (ext = extension). If you are running Cpanel or another editor you regulary won’t have this issue, but you never know. Always try to remove this files, you really don’t want to have an “index.php~” file in your DocumentRoot, because it’s content can be seen by others.

VSDan: Boby, excellent post =) I can emphasize enough that it is CRITICAL that people backup their sites – remotely and locally. We have regular tape backups of our server, and mirror file-for-file locally on our office computer (which we store on hard drive and DVD). And, good thing. Our server crashed a few days ago, and we were able to completely restore from tape backup within a day – gigs and gigs of files in hundreds of directories. The last backup was 02/08, but we were able to restore critical data files from our local backup as it was more current (02/21). And to make this story even scarier, the replacement server crashed a day after setup. so, we had to do this twice. What are the odds of struck by lightning twice =) And between the two replacement servers, a Dos (Denial of Service) attack apparently from Vietnam (or via open Vietnam-based proxy). So everyone listening, learn from this. Backup, backup, backup. Thanks again, Boby for your sage advice to some of the newbies (and even some of your most seasoned webmasters).

Boby: Regarding backups … my homepage is hosted on a root server of a friend of mine. He is doing all administration on it, I am doing just for my domain. He is the expert.

 There are two more friends that have each another root server. Every night a full backup is generated on each server and stored on the other two servers. So if you have many data and loose your server, then we apply murphy’s law and the second server is down too, we still have a backup on a third server 

 Each backup is stored one week. If nothing happens, at the end of the week the last backup is kept, rest are removed.
This is just an example for advanced users that have full server access. Usually you have just a Cpanel or Plesk or whatever and the hosting company is doing the backup, but for me they have failed once with the backup and I loosed almost everything. At least I had an older one on my PC 

And now to your Vietnam attack … I can bet the attacker was not a Vietnamese. An experienced attacker will go through several proxies and servers all over the world and then attack. So you will see just the last one. You can track the from that server back but it’s very hard to go back through all servers the attacker has used. It’s almost impossible to track a good cracker (not hacker, ’cause that’s the good guy).

VSDan:

That’s a good backup system too =) I’m going to reschedule our tape backups more frequently. Every two(2) weeks is good for smaller sites. But ours is just too large and too dynamic in terms of writing to the server – that in two weeks, that can be quite a lot of data to restore from our local backup. Daily would be a tad overkill in our case.

The DoS persisted for a few hours (I did block the IP when I discovered it), and always from the same IP. And once I blocked the IP, the attack ceased almost immediately. No similar attacks preceded the DoS, and none followed – knock on wood =) This is uncharacteristic of a proxy or distributed DoS. This is not unusual in that part of the World, as they seem themselves as invincible as often their ISP’s turn a blind eye to it and they outside the arms of the law of most nations.