Today I want to talk about the benefits of defense in depth. The term “defense in depth” is used in a variety of ways. I like to think of it as a general term to describe any system where you have multiple layers of protection. If one layer fails, another layer is there to provide a backup.

As I wrote about a while back, we were subjected to a script kiddie attack. Fortunately they were not successful in breaking in to our systems, but, due to some bugs in how we handled some of the requests, they did end up causing a denial-of-service attack on our database server. Normally, this would just mean the website was down for a while, but, due to several other bugs we ended up showing a screen that should only be shown to developers that included our database password and other information needed to connect to our database. Oh #@$%^ is really the only thing to say then (particularly because when we first realized this, we had no idea how long this problem existed). After having visions of user email addresses suddenly ending up in the hands of spammers, we realized we were much better off than we thought. Our database is set to be accessible only from our web server. So, unless someone could break into our web server, they still couldn’t access our database (and if they can break into our web server, we have bigger problems).

Thankfully for us, even though several layers of protection failed – we had bugs in our search mechanism, we had bugs in our debugging code and some secret information was revealed – our database was still protected.

Another website I run was also attacked recently. A popular open source product had a vulnerability and before we could patch it, the website was attacked by several people. They were able to exploit the vulnerability to upload a PHP file to our web server. Then they tried to run it and it would have succeeded, except for some settings on the web server that didn’t allow files with certain permissions to be run – and uploaded files have those permissions set. Thus, the attackers got on the machine, but couldn’t run their scripts. After I patched the code to remove the exploit, I also added further protections to the server so only graphic files would be served up from the uploaded files directory (if you’re a server administrator, I used the .htaccess to only allow jpg, gif and png files. Perhaps in a future entry I’ll talk about .htaccess rules).

Both of these examples show how having multiple layers of protection are crucial to having a secure website. We use this same principle when we protect our home or office. Even if we have an alarm system, we still use a deadbolt lock. If an intruder breaks the lock, they still have the alarm system to contend with (or in some houses, an angry dog too). We need to think of how we can protect our web servers and other technology infrastructure with multiple layers of protection.