1. Create a Non-Root User

   When your server is provisioned, you’ll generally only be given an IP address and a root password. That’s all you need to SSH in to the server as the root user for the first time. It’s bad practice to log in as root for a few reasons — if you log in as a single user and only “su” to root access when needed, you’re less likely to accidentally damage your own system by deleting an important file or providing the wrong options or path to a command. It’s also harder for someone to attempt to break into your server by brute force if they can’t log in directly as root; they’ll need to find a way in as another user then additionally gain root access.

   The first thing you’ll want to do is create a user for yourself to log in as in the future. In most Linux distributions, that’s as easy as typing “useradd [username]” or “adduser [username]“. To set the password for your new user, type “passwd [username]” and you’ll be prompted to supply the new password.

2. Disable Root Logins Over SSH

   Now that you have a second user account, reconnect to your server as that user. Now you can use “su” to gain root access again and edit the SSH configuration file. To do so with the pico text editor, type “pico /etc/ssh/sshd_config”. You’re going to make two changes:

   Find the line Protocol 2, 1, uncomment it, and change it to Protocol 2. Find the line PermitRootLogin yes, uncomment it, and change it to PermitRootLogin no.

   Save the file (CTRL+X, Y) and quit your text editor. Now restart the SSH service (/etc/rc.d/init.d/sshd restart) and it’s no longer possible to log in as the root user over SSH.

3. Disable Telnet

   Telnet is another way to connect to your server, but unlike SSH, is not encrypted. As it’s less secure and just another opportunity for someone to attempt to gain access to your server, it’s best to simply disable the service. To do so, edit the telnet configuration with “pico /etc/xinetd.d/telnet”.

   Find the line that reads disable = no and change it to disable = yes.

   Now, restart the xinetd service with “/etc/rc.d/init.d/xinetd restart” and prevent telnet from starting on boot with “/sbin/chkconfig telnet off”.

4. Install APF (Advanced Policy Firewall)

   APF is a policy based firewall for Linux. It’s very simple to install and configure.

   1. Download it to your server by issuing “wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz“
   2. Extract the file with “tar -xzf apf-current.tar.gz”
   3. Enter the directory that was created, for example “cd apf-0.9.6″
   4. Install APF with the provided script “./install.sh”
   5. Edit the configuration file: “pico /etc/apf/conf.apf”

      Find the line USE_DS=”0″ and change it to USE_DS=”1″ to enable the DShield.org block list. Then you’ll want to edit the ports APF will allow traffic through on your server by finding and updating the following lines as appropriate:

      # Common ingress (inbound) TCP ports -3000_3500 = passive port range for Pure FTPD
      IG_TCP_CPORTS=”20,21,22,25,26,53,80,110,143,443,8443,2222,123,3306,10000,8767,14534,51234″

      # Common ingress (inbound) UDP ports
      IG_UDP_CPORTS=”21,22,53,123,8767,14534,51234″

      # Egress filtering [0 = Disabled / 1 = Enabled]
      EGF=”1″

      # Common egress (outbound) TCP ports
      EG_TCP_CPORTS=”21,22,25,80,443,8443,43,2222,123,8767,14534,51234″

      # Common egress (outbound) UDP ports
      EG_UDP_CPORTS=”20,21,22,53,123,8767,14534,51234″

   6. Start up APF to test your settings. “/usr/local/sbin/apf -s”
   7. If everything looks right (you’re still connected, you can still access whatever ports you need to access, etc.) you can edit the configuration file again and change DEVM=”1″ to DEVM=”0″ to disable development mode.
   8. Restart APF and set it to start on reboot with “/sbin/chkconfig –level 2345 apf on”
5. Install BFD (Brute Force Protection)

   BFD is designed to work alongside APF by scanning your system’s logs for a large number of failed login attempts, and issuing the command to APF to deny that person’s IP address from connecting again. This protects you from attempts at “brute forcing” access to your system, such as repeatedly trying to log in to common account names using a dictionary of common passwords.

   To install BFD, follow the same procedure as above, using the archive at http://www.rfxnetworks.com/downloads/bfd-current.tar.gz.

   The configuration file for BFD is located at /usr/local/bfd/conf.bfd if you want to change any settings, including the ability to have a daily report of failed login attempts e-mailed to you.

6. Install mod_security

   mod_security is a module for the Apache web server that lets you filter out certain requests from being processed. This lets you stop many types of vulnerability exploits on your web server, especially those aimed at sending spam through web forms and issuing commands through known vulnerabilities in some PHP scripts.

   The download and installation process is slightly different depending on what version of Apache you’re running, but it only takes a few minutes to install in most cases. You can download and find documentation at the ModSecurity website.

7. Check Services are Up to Date

   While you just purchased your server, the software that came with it may already be out of date, and potentially vulnerable to newly discovered exploits. A good place to keep track of high risk vulnerabilities in the wild is the McAfee Threat Center.

   Many Linux distributions come with a program such as yum or up2date which you can use to check for updates to installed software on your system automatically. Make use of them on a regular basis and check with the websites of the service creators for updates and patches.

8. Tune Apache and MySQL

   For most people, Apache and MySQL will work relatively well out of the box. If you intend to put considerable load on the server, it’s worth doing a little tuning before you go live. There’s documentation for tuning the settings of both apache and mysql on their websites, and an excellent blog at mysqlperformanceblog.com.

   If you’re going to be running PHP applications, a byte code cache such as APC can significantly boost performance as well.

Follow this checklist to get up and running, ready to host your websites. Remember that managing a server is an ongoing process. You need to keep up with software updates, vulnerabilities, and performance bottlenecks on a regular basis to keep things running smoothly.

Once I took on a job working on a PHP application larger than one file in size (Contact Administrator), the single file per window, single undo abilities of notepad didn’t cut it anymore. I upgraded to TextPad. I gained the convenience of a single window for all open files, syntax highlighting, multiple levels of undo, and the ability to replace patterns in all open files. My routine still consisted of opening all the files in a project in TextPad, writing code, saving, uploading by FTP to the server, and testing the changes live.

It wasn’t until 2005 that things changed significantly. I discovered vim, starting the third phase. I had been managing two servers to run my websites for a few years by now but had only known vi as a text editor that was hard to quit out of. Then I met Amir while working at The Math Forum, a “vi guru”. His copy had color, syntax highlighting, edited multiple files at once, transformed huge blocks of text at a time, ran regular expression replacements in a flash. Watching him code got me hooked. For nearly a year I worked directly on my servers over SSH in PuTTY, editing code on the server with vim.

Then W3Counter came along. It was my most ambitious project yet – a full-blown web statistics service, a competitor for Google Analytics and the likes, to support thousands of simultaneous users, and I wanted to finish it in under a month. It ended up taking around two. This project was bigger and more complex than the PHP scripts I had worked on before, and my knowledge of the language had advanced much past when I developed Contact Administrator. I had gained experience in Java, MVC, frameworks, ORM. I wasn’t going to tackle something like W3Counter with huge files of procedural code.

That’s when I moved on to my current environment. My editor of choice is Eclipse with the PHP extensions, released as the Eclipse PHP IDE. It gives me a view of my directory hierarchy, a browser for my class APIs, code completion and an internal browser.

I combine that with WAMP5 for a local copy of Apache, PHP and MySQL. I keep my development environments up-to-date, and deploy to my live servers with Subversion. Eclipse has TortoiseSVN plugins for easy integration. I set up the Subversion repository after reading Pragmatic Version Control Using Subversion.

What I’m currently working on is a project on top of the Symfony framework. I found it easiest to start off with the sandbox copy rather than linking in Symfony externally from the project. One hitch with this is that the Symfony CLI requires PEAR, which WAMP5 didn’t come with installed, and the included installer script didn’t work correctly (on Windows Vista at least). This go-pear copy worked fine when run from the php directory of my WAMP installation.

When I do still need to transfer a file to a server that’s not under SVN control I’m back to the same software I used in 1996: WS_FTP LE.