Other ways to protect your server.

Consider using a non-standard server package.

Pros.

  1. Exploits are almost never shared from one server family to another.

  2. The most popular packages are the most tempting targets for monetization by spammers.

  3. The most popular packages are the easiest targets for skript kiddies to kill.

  4. As long as your package works with php, most of the scripts on the net will work.

  5. Small projects need love too. Try freeproxy or JanaServer

Cons.

  1. Exploit fixes are done faster on the popular packages, because there are more people coding for them.

  2. Almost all servers have been exploited at one time or another.

Try a non standard file structure.

Try things like putting all the server files by themselves on their own hard drive, separate from system files and MySQL. If you do this, you can also put in a bogus /proc/self/environ file, and a bogus /etc/passwd file and seriously put a crimp in some automated hacking processes. Directory traversals are nasty, but it's nice when they can't get to where the goodies really are. Most nogoodniks are expecting your setup to be a default one. Most hacks are based on this.

Use a software firewall.

I cannot tell you how many SysAdmins have been undone by the arrogance of believing their router firewall, or seperate firewall appliance in the network chain will be 100% protection. Here are some ways this can fail...

  1. Server reflection inside the lan. If someone spoofs their IP when connecting to the webserver, and crafts their packet such that it is supposed to return to a local IP, and port that may be running an open lan service (file sharing, ping, whatever), they can cause a DoS attack.

  2. Worse, if they do the above attack, but wrap their packet in such a way that it strips off the first layer (this can be done by some poorly written webserver apps), they can actually plug a virus or downloader into the system, which brings us to...

  3. Hostile software on the local side of the wall. Is your server alone with the firewall? Is it screwed down tight enough not to allow other processes to launch without local terminal activation? All you need is just 1 bad downloader on the LAN side of your firewall and it's all over. Consider a software that is on an accounting machine in the office of your business, and that one of the people there just had to show their cow-orkers this "cool site", which summarily plugged a remoting tool in there that will remain quiet till 1900 hrs local time, then call home, and give the hacker who slipped it in on the cool site, complete control of a machine in your LAN. A softwall would not let this nasty program out without express consent of a user. (Windows firewall does NOT count as it allows automated rule changing on installs. Once windows firewall requires user authorization to give a program access, then I will OK it. Till then, I spit on windows firewall!) Check my firewall page for better options.

  4. Physical plant attacks. Remember your friend who came over with her 13 year old kid in tow? Did you even see him back up to the machine and plug in his USB key nonchalantly? Well, like the above problem, you now have hostile software running on that machine, but, with a software firewall, unless he took control of the machine and authorized the access, the harm never was able to call home and deliver your goods to his control.

Use a hardware firewall.

Most routers will do this job just fine without modification. When you forward ports to your machines, be selective. Avoid forwarding any extra ports below 1057. Avoid using standard ports on programs if they can be customized. It goes without saying that a softwall alone is weak, due to the fact it is running on the machine to be protected. A purpose built hardwall is better, but when you run both a softwall and a hardwall, you should be fairly safe.

Remove unneeded items from the TCP/IP stack of the server's NIC.

If your server does not need to share files on the network (it should be isolated and only accessible through FTP, Telnet, and/or local terminal), you can remove some common items that just are not needed from the connection stack in Windows. From personal experience these are...

  1. File and Printer Sharing for Microsoft Networks (This is the worst of the worst to expose to the world.)

  2. QoS Packet Scheduler. (Removing this may help the server survive some Denial of Service attacks, as it can get confused when flooded.)

  3. Link-Layer Topology Discovery Responder. ( If #1 is done, this is not needed anymore, and will only serve to be a target for a malformed packet.)

Your needs may vary.