Coastal Web Development

I was recently hired to do a PCI compliance scan and complete the remedial work to bring it up to standard. This was on a CentOS5 box. The tool I was using to do the scanning was pretty good, but like all scanning tools plays “the numbers game.” This means it simply looks at the versions of certain services and flags it if that version is known to be vulnerable. In my case, Apache and PHP were causing the most red flags. There were some XSS (cross-site scripting) vulnerabilities addressed in Apache 2.2.8 and my server header was showing 2.2.3. PHP was the same story, with several DoS and code execution vulnerabilities fixed in 5.2.7, and I was apparently running 5.2.6. Obviously vulnerable, right? No and yes. I’ll explain why this is the case, and how you can tell what you’re really vulnerable to.

Linux distributions such as Red Hat (RHEL, Fedora, CentOS) sometimes rely on “back ports” or patching the existing version of the service, fixing the hole without updating the version number. This means a lot of false positives on the scan, which you can clear up with the rpm tool, grep and a web browser. Let’s start with Apache – the scanner says I am running 2.2.3, which is obviously vulnerable to some cross-site scripting (XSS) attacks. Being vulnerable to XSS is a PCI compliance fail. So I checked out the changelog for Apache 2.2 and saw that CVE-2008-2939 was fixed in version 2.2.10. We then run:

[root@steve ~]# rpm -q --changelog httpd | grep CVE-2008-2939
- add security fixes for CVE-2008-2364, CVE-2008-2939 (#468840)

This shows that someone from RedHat applied the patch to fix this vulnerability, but the version number wasn’t updated. This is a clear false positive. If you don’t find the CVE number listed in the changelog, pipe the output to less and look for anything mentioning the affected module or an upgrade to a version that includes the fix. For example, in my case, PHP 5.2.7 fixed a bunch of security problems in prior versions, some of which are a PCI fail.

When I looked through the PHP rpm changelog, the last thing I found was the update to 5.2.6 with no mention of 5.2.7 or patches for the issues addressed. Checking out the PHP changelog showed a lot of security fixes for 5.2.7. I ended up using a PHP 5.2.8 rpm from atomicrocketturtle.com which included the fixes. Using a third-party repository isn’t particularly ideal, but given the choice between that and either building from source or applying patches to a source rpm, I picked the third-party.

A few final thoughts:

• You may find it easier to disable a module or service than patch it. If a module or service isn’t required, then disable it. This is good security practice.
• For those services that are only required locally, such as database and mail services, bind them to the localhost interface and firewall them.
• Don’t put all your faith in automated scanning – they are a tool, not an absolute solution. You will need to go through the results yourself, or hire someone to help you.

If you’re looking to hire someone to set up a PCI compliant LAMP stack or audit an existing one, please contact me for an estimate.

If you have your DNS hosted in one place (say DNS Made Easy) but host your content on 1and1.com. 1and1 allows you to do this without transferring the domain to them. The problem is they appear to not set the DirectoryIndex directive for hosts using external DNS. This can be overcome with either creating or adding to the .htaccess file in your site’s root directory:

DirectoryIndex index.php

That’ll work for WordPress, or most other PHP-based sites. You can always change it to index.html if that’s what your site’s index page is.

I had a client machine reboot today and ssh wasn’t configured to come up on boot. This was a CentOS Plesk machine at my least favorite hosting provider, Media Temple. Secure shell isn’t mentioned in the services section in Plesk, and Media Temple doesn’t have a remote console feature. So in order to avoid submitting a ticket and waiting for Media Temple’s slow support, I managed to restart sshd using Plesk’s web interface to cron (Scheduled Tasks) to start it. Here’s what I did:

• Got the current server time (it might not be in your timezone) by going to Server > Time
• Went to Server > Scheduled Tasks and created a new scheduled task 2 minutes ahead of the current server time. The task should run /etc/init.d/sshd start.
• Wait.

Hopefully within 2 minutes sshd is started. Don’t forget to remove the scheduled task, and ensure that sshd is configured to start on boot (chkconfig –levels 345 sshd start or whatever your distro uses.) Honestly I think Media Temple should have a backend console similar to how other VPS providers such as Slice and Linode do it. You’re paying enough.

Often when deploying a new web application you need to restart the apache process. If you’re deploying the application with vlad the deployer as a non-root user (which you should be doing) and you need to restart apache, this can be a little tricky. Luckily there’s a Linux command called sudo which allows you to run commands from a non-root user’s account as though you were root. We’ll limit the commands to just controlling the apache process. It’s a bad idea to give open access with sudo since the user can simply run “sudo su -” and become root.

In order to edit the configuration file that sudo uses (/etc/sudoers btw) we use the visudo command, which edits the file in a safe way by checking for simultaneous users editing the file, parse errors, etc. The idea being to minimize the number of mistakes that can be made. You’ll need to be root (or have sudo permission!) to edit the file:

  # visudo

This brings up an editor screen, whatever you have configured as your default editor. The example below is for Ubuntu, so if you’re using a different distro or web server you’ll need to change the location of the init scripts accordingly (i.e. Ubuntu uses /etc/init.d/apache2 but your distro may use /etc/init.d/httpd or /etc/init.d/lighttpd if you’re running Lighttpd.) I’ll also assume you’re calling the deployment user deploy.

Here are the lines you want to add:

Cmnd_Alias     APACHE = /etc/init.d/apache2 start, /etc/init.d/apache2 stop, /etc/init.d/apache2 restart, /etc/init.d/apache2 reload
# Allow the deploy user to control apache
deploy ALL=NOPASSWD: APACHE

Now save the file, and log in as your deploy user. You should be able to restart apache with the above commands by running:

deploy@steve:~$ sudo /etc/init.d/apache2 restart

Now in your vlad tasks, use the sudo version above to kick the webserver over when you do a deploy:

         # desc "Starts Apache"
         remote_task :start => :settings do
             run 'sudo /etc/init.d/apache2 start'
         end

         # desc "Restarts Apache"
         remote_task :restart => :settings do
             run 'sudo /etc/init.d/apache2 restart'
         end

         # desc "Stop Apache"
         remote_task :stop => :settings do
             run 'sudo /etc/init.d/apache2 stop'
         end

In some cases you want to set up an “upload only” FTP account, which allows a user to upload files, but not list directories, download or delete files. This is typically used when you want to give out the credentials for an account to multiple people so they can upload content (mp3s, videos, resumes, etc.) but not affect what others are doing.

cPanel gives you two choices of FTP server – PureFTP or ProFTP. PureFTP is simpler and smaller if you just want a quick and dirty FTP site. For more advanced configuration, ProFTP is recommended. ProFTP has a feature that is a lot like Apache’s .htaccess file, allowing you do make per-directory configurations without modifying the main config file. Any directives that can appear in a ProFTP <Directory> stanza can appear in an .ftpaccess file and will be applied to the directory in which the file resides.

First make sure you’re running ProFTP and not PureFTP – you can change this setting with no loss of information from within WHM. If you don’t have WHM access, you’ll need to ask your provider to switch FTP servers. Here’s the config for an upload-only FTP account called ‘uploadonly’ – the account will need to have been created from cPanel first. Name this file .ftpaccess and put it in the directory where you want the uploads to appear. I usually create a separate directory and apply quotas.

    <Limit ALL>
        DenyUser uploadonly
    </Limit>

     <Limit CDUP CWD XCWD XCUP>
        AllowUser uploadonly
    </Limit>

    <Limit STOR STOU>
        AllowUser uploadonly
    </Limit>

This type of configuration where we deny everything, then allow only what we want is more secure than allowing everything and denying specific operations. More configuration options are shown on ProFTP’s configuration page – anything that can belong in a <Directory> stanza can go in the .ftpaccess file and avoids having to edit cPanel’s ProFTP configuration file.

Why host in a foreign country?

You’ve had great success with your site in English, and have developed foreign language versions – how do you go about getting more traffic to these sites? Local inbound links with anchor text in the right language, using the correct country’s top-level domain and verifying the locale within Google webmaster tools. The content should also come from a server located in that country. This can either be accomplished using a content proxy, or by hosting the sites with a foreign ISP.

Content proxies for foreign language SEO

Proxies are servers that accept connections from users, fetch content on their behalf, then relay the content back to the original requester. These proxies can also cache the results, so they offer a speed improvement for users. The content appears to be hosted on the foreign server, when in fact it is just holding a copy of the content. This is especially beneficial for dynamic database-driven sites – if you were to really host the foreign language version of your site, you might need to maintain copies of your database on remote machines. Not only that, but a proxy can run on a VPS (Virtual Private Server) machine with no problem, taking up fewer resources and costing less. Apache, Nginx, Lighttpd or squid can be used.

Hosting foreign language sites for SEO

If your site is mostly (or entirely) static HTML, images and CSS hosting a copy with a foreign ISP might be a better route. In this case, you have no database and are simply serving static files. Site with few scripts and no databases are perfect for foreign VPS hosting, again using Apache, Nginx or Lighttpd. Caching can be turned on to improve performance – although the actual content is hosted as a file on the server, the web server software can be configured to maintain a copy in memory, improving speed.

Performance considerations with foreign hosting

The “regular” tricks of the trade should be employed, especially since most VPS systems are not as powerful as a standalone server, and the networks in some countries are not as robust as North America. Using in-memory caching, HTTP keepalives, HTTP expiry (Apache’s mod_expires for example), bundling external JavaScript/CSS files and minimizing image use and size are all well-known techniques that will improve performance. The main goal should be to minimize the number of requests made to the server, as well as limiting the size of the requests. Often times latency is a bigger killer than bandwidth.

Looking for foreign hosting?

I provide monitored VPS hosting solutions in the following countries:

• USA
• UK
• Australia
• France
• Italy
• Germany
• Spain
• China

Please contact me for a foreign hosting quote. Also note that I provide foreign server setup and maintenance for other services including web proxies and backup servers.

When clients ask me to recommend a DNS provider, I used to suggest UltraDNS. UltraDNS uses Anycast routing which gives DDoS protection as well as excellent performance, since clients get service from servers that are closer to them. UltraDNS has massive redundancy, which also makes it a great choice from a security perspective. I started using DNS Made Easy about 2 months ago and I was blown away. They use the same Anycast technology UltraDNS does, they have redundant servers (they added 100 servers to their network last year) in multiple countries, their interface is clear, simple and easy to use, and most importantly they are a fraction of the cost of UltraDNS. Their most expensive package has more queries than you’ll ever need and is still less than $150/month. Smaller sites would be able to use their less expensive package which is a little over a dollar a month ($14.95/year.)

The DNS Made Easy interface is really simple to use, unlike a lot of the DNS managers from web-hosting companies such as GoDaddy or 1&1. Adding domain-level redirects is extremely simple and straightforward, as are the usual suspects like adding A records, CNAMEs and setting TTLs. One feature I really like from DNS Made Easy is the ability to do a “soft” redirect. If you change your domain, you need to redirect your old URLs to the new one. This is especially important if you have a lot of indexed pages. DNS Made Easy has a “soft” redirect feature, which keeps the path information for the new URL. This means your URLs that are currently indexed (http://olddomain.com/some/indexed/url.html) gets redirected to the “right” place on the new domain (http://newdomain.com/some/indexed/url.html). The same thing can be done using an Apache rewrite rule if you don’t want to use DNS Made Easy. For example, a 301 “soft” redirect to newdomain.com:


RewriteEngine on
RewriteBase /
RewriteRule ^(.*)$ http://newdomain.com/$1 [R=301,L]


One thing that turns a lot of people off about UltraDNS is the cost. DNS Made Easy is based on the same AnyCast technology but is much,
much cheaper. For a little over a dollar a month you get 3 domains with 1 million DNS queries per month. With UltraDNS being $100 per 1,000 queries,
the prices don’t even compare. Also, UltraDNS charges by resource record (i.e. the more A, MX, CNAME records you have, the more you pay)
but DNS Made Easy does not.

As a final note, even if you’re not convinced to use DNS Made Easy for your primary DNS needs, it is an inexpensive way to
have secondary DNS in case your primaries go offline. DNS Made Easy can act as a slave for your own master running BIND. This is a great combination
for those of us who like to do it ourselves but don’t have the resources (or money!) to build our own redundant, Anycast network.

Note that this review was not paid for, or endorsed by DNS Made Easy. Nor am I an affiliate.

Most people, SEOs especially will have heard of and understand what proxies are. For those of you who don’t know, proxies allow you to “tunnel” your browser’s traffic through another computer, making it seem like you are surfing the web from that location. There are specific services out there that make your traffic more anonymous by doing other things like blocking cookies, or even certain sites. Those web filters that keep our kids “safe” are a type of proxy (although most are easily bypassed.) Most proxies are owned by companies to which you pay a fee for their use, or you can search for “open proxy list” to find some. The downside to using these is mainly lack of control – you have no control over if the proxy is forwarding HTTP headers (making it known that you’re using a proxy), no control over DNS or who else is using the proxy. I’ll explain why these are important shortly.

If you’re optimizing for US-based or UK-based traffic it doesn’t make sense to check your SERP ranking from Canada. What if your site is in a foreign language such as Italian? It makes more sense to search from an IP that is geographically located in the area you’re trying to analyze. That’s where proxies come in. You simply have a web proxy set up in a data centre in the right country and you’ll instantly have a more accurate picture of where you rank in the SERPs. We can set proxies up in a variety of locations such as Canada, US, UK, or other European countries such as France and Germany.. These are dedicated servers with dedicated IP addresses, configured to not add HTTP headers that tell others you’re proxying. These servers are dedicated to you, and cannot be used by anyone else. If you’re interested in having us set up one or more proxies for you, please contact me.

If you run any kind of SEO tool, you’ll know proxies are a must. Those of us without Google API keys must rely on “scraper” type tools that do repeated searches. These tools are not scalable from one IP, meaning you hit a threshold and your tool stops working (I hate it when that happens.) If you proxy your requests through several different dedicated proxies, you can avoid this. And for those of you who use open proxy lists – they are unreliable, slow, insecure and remember that you have the list as well as thousands of others, including the search engine companies. Dedicated proxies are reliable, fast and they belong to you. You control who has access from where.

Developers can use dedicated proxies to test applications quite easily. This is especially important if your software does anything with IP geolocation data, such as taking users from the UK to a different domain. The only surefire way to test this is from a UK-based IP. Perhaps you’re in the process of upgrading your site and want to test it one the “live” domain name before making the DNS switch. You control the DNS resolution on your proxy, so you can make your site resolve to a different IP through the proxy. This allows you to flip back and forth between the old and new sites.

If you’re interested in having a dedicated proxy set up, please contact me for a quote. Proxy management runs at $30/month for North America and most European countries and includes setup, monitoring and updates such as adding more users, and configuring password-protected ports.

I found a few init scripts for trac, but they were all Debian-based, using ’start-stop-daemon’ which does not exist in RedHat-based distros. Here’s an init script that will work with RedHat.

#!/bin/bash
#
# tracd Start/Stop tracd.
#
# chkconfig: - 62 38
# description: tracd
#
# processname: tracd
#
# Author: Elliot (info@coastalweb.ca)

# Source function library
. /etc/init.d/functions

# Get network config
. /etc/sysconfig/network

RETVAL=0

TRACD_PORT=8000
TRACD_USER=tracd
DAEMON=/usr/bin/tracd
PIDFILE=/var/lock/subsys/tracd
TRACD_DIR=/subversion/trac

start() {
    echo -n $"Starting tracd: "
    daemon --user $TRACD_USER $DAEMON --port=$TRACD_PORT --daemonize \
                 --env-parent-dir=$TRACD_DIR
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch $PIDFILE
    return $RETVAL
}

stop() {
    echo -n $"Stopping tracd: "
    killproc tracd
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f $PIDFILE
    return $RETVAL
}    

restart() {
    stop
    start
}    

reload() {
    stop
    start
}

case "$1" in
  start)
      start
    ;;
  stop)
      stop
    ;;
  status)
    status tracd
    ;;
  restart)
      restart
    ;;
  condrestart)
      [ -f $PIDFILE ] && restart || :
    ;;
  reload)
    reload
    ;;
  *)
    echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"
    exit 1
esac

exit $?