Category: Confused Configs

Typical Server Setup

Since there are so many little tweaks that I do to my regular web-server setup, I felt that I should put down some of my thoughts here, for the purpose of documentation.

Operating System
I invariably go with Debian. If the VPS provider does not provide a Debian option, I will not buy a VPS from them. When choosing between Debian installs, I tend to choose 32-bit images because I do not believe in having a single large server with more than 4GB of RAM. A 32-bit installation allows me to do some wonderful optimisations. I can run a MySQL and web server with PHP5 in under 64MB of RAM on a 32-bit Debian install.

Security
Firstly, security. My firewall of choice is Shorewall because it has been around for ages and I have been using it for just as long. It has only gotten better with age. I am one of those who believes in host-based security. Every person should be vigilant and take care of themselves when going out – same with servers. I will just tweak the example configurations provided with the documentation pack.

Next, I will install Dropbear and remove OpenSSH server. The reason that I do this is largely due to resource consumption. Since the SSH server is rarely used except for administrative work, I just use a light-weight one instead, to conserve RAM. I will set it with the “-w” option to block remote root logins. Other than that, I leave things as they are.

Database
Since most Open Source web applications tend to use MySQL as their database, I need to configure this. Depending on the amount of RAM available, I will select the example configuration provided with the documentation pack. The amount of recommended RAM is stated in the example config files themselves. I will tweak it by adding the skip-networking, skip-bdb, skip-innodb flags to reduce RAM usage.

Web server
I prefer to use Lighttpd because it provides a lean web-server that is easy to configure. IMHO, Nginx is not as friendly to configure while Apache is too resource intensive. There are a number of configurations that I will do with this. I will set server.tag to emit some useful information – typically the name of the actual machine that is serving up the page. I will disable server.dir-listing. I will set the SSL certificates if required and set the algorithm to AES128-SHA to conserve CPU resources. I will also tweak the FastCGI numbers depending on the resources and expected performance of the server.

Web application
I tend to run PHP5 because that is what most Open Source stuff use. I will tweak it by turning on zlib.output_compression, reducing memory_limit and turning off expose_php for security and performance purposes. The actual values to tweak will depend on the resources available on the server.

Some points to note:

If using an opcode cache like XCache, it is important to reduce the number of FastCGI processes and increase the child threads because the cache is stored per-process. Otherwise, it is better to reduce the child threads to zero and increase the FastCGI processes to reduce resource consumption.

Miscellaneous
Other minor tweaks that I will install would be things like etckeeper that helps to keep track of maintenance issues. I may also install cron-apt to help with some update notifications. I also reduce swappiness to improve memory performance.

Day 2 – SQL Injection

We learned about SQL injection today and were just randomly picking Malaysian websites to test it on. This is the result that I managed to get with a local organisation’s website (which shall remain nameless). I managed to find out the version of MySQL server that they were running (5.0.45) and also the account credentials for that MySQL server (root@localhost).

Nice!

Our trainer was able to exploit this further and enumerate a whole bunch of stuff, including all the user login credentials for their MySQL database, a list of all their databases and column fields, a dump of all the records of any selected database and more. This is not a bad reflection on MySQL as our trainer says that MySQL databases are amongst the hardest to attack.

However, if there system administrator is not doing their jobs correctly, things can get screwed.

Hacker Halted – Day 1

I attended Day 1 of Hacker Halted today. I signed up for Workshop 1 – on web-application hacking – because I wanted to learn more about it. Our morning started with mainly basic stuff on the underlying mechanism behind web applications – HTTP protocol, DNS services and what nots.

Our afternoon session was more interesting, with our trainer – Sean Arries – showing us the information gathering aspect of web-application hacking (vulnerability analysis). This is done in order to increase the attack space of the target. The thing that I learned from this section of the training is that – sites are far more vulnerable from side-channel and internal attacks than direct external attacks.

The tools that I already knew (and are part of every System Admin’s arsenal) were things like whois, dig, nslookup, host and other network layer stuff. However, at the application level, I learned how to use XSS ME. Manually testing cross-site scripting (XSS) is quite fun.

The basic techniques shown were really useful. We even practiced it on a number of prominent local Malaysian sites. Very interesting. Tomorrow, we get to the actual act of attacking web applications (penetration testing) and see if we can pwn any machines. I am looking forward to hacking my own websites.

FreeNAS with D410PT

I bought myself a D410PT and 1GB of DDR2-800 memory yesterday for only RM290! I decided to use it to build a better NAS for my home. However, there were some issues and I thought that I should note them down here.

Power Supply
My first problem was the ATX power supply. For this purpose, I decided to use an old 120W power supply that I had lying around from an old VIA machine. Turns out that it only had 20 pins while the D410PT had a new 24 pin power socket. However, with some research I found out that the extra 4 pins were not strictly necessary as they were there for extra current. Seeing that this is a low-power design, the extra current was not quite necessary. According to the D410PT user manual, it only takes up 40W under full load with a bunch of devices connected. So, safe.
Network Chip
Another problem happened when I started up FreeNAS. It could not load up the built-in network. Turns out that the chipset used on the D410PT was not recognised by FreeNAS 0.7.1 (latest stable). However, after using the latest nightly build (5266), the link activated. So, I was able to get the network working. Unfortunately, the D410PT only has a 100Mbps chip but that is good enough for my home NAS.
Old Config
At first, I tried importing the old config backup from my previous 0.6.9 server but that caused more problems than it solved. It made it difficult to make configuration changes as the 0.7.2 server would complain about config errors. I guess that something must have changed in between. So, I ended up resetting the configuration and doing all of it manually. The trickiest part was to make sure that the old drives that I moved over from the old machine did not get reformatted or deleted by accident. Otherwise, it worked fine.

Lighttpd SimpleCDN

I have recently tried to enable CDN integration to a bunch of servers in order to reduce load. In some cases, the CMS used had a good CDN plugin/module, such as the one used on this blog. It will automatically rename urls in the output buffer before sending it to the client.

However, I longed for a more permanent and independent solution. So, I decided to use HTTP redirects to point things towards the CDN. Since I use lighttpd, the result is the following configuration snippet:


server.modules += ( "mod_redirect" )

$HTTP["host"] == "www.example.com" {
$HTTP["useragent"] !~ "^SimpleCDN" {
url.redirect = (
"^/(.*)\.(gif|jpg|jpeg|png|css|js|mp3|swf|wmv|mov|mp4)$"
=> "http://www.example.com.lg1.simplecdn.net/$1.$2"
)
}
}

That worked!

Now, all requests for various static files (like images and media), will be immediately redirected to the SimpleCDN mirror bucket that is an Origin Pull CDN. Sweet. This should take a whole load off my server and since this is done at the web-server level, it won’t even consume much resources.

Lighttpd Server Name Indication (SNI)

I installed a new web-server today and tested out its SNI features. SNI solves the problem of hosting multiple virtual hosts on the same server running SSL. In the past, it was not possible to present a different certificate for each virtual host, necessitating the use of other techniques.

This was how I did it at first:

$SERVER["socket"] == "10.0.0.1:443" {
ssl.engine = "enable"
ssl.pemfile = "www.example.org.pem"
}
$HTTP["host"] == "foo.example.org" {
ssl.pemfile = "foo.example.org.pem"
}
$HTTP["host"] == "bar.example.org" {
ssl.pemfile = "bar.example.org.pem"
}

However, after setting it up, it successfully presented different certificates but it seemed to present the wrong ones for different virtual hosts. After mucking about the Internets, I came to the conclusion that my configuration file was in error. A proper SNI configuration should be configured as such:


$SERVER["socket"] == "10.0.0.1:443" {
ssl.engine = "enable"
ssl.pemfile = "www.example.org.pem"

$HTTP["host"] == "foo.example.org" {
ssl.pemfile = "foo.example.org.pem"
}

$HTTP["host"] == "bar.example.org" {
ssl.pemfile = "bar.example.org.pem"
}
}

After that it worked magically. Wow for nested configs!

Update: Turns out that I spoke too soon. The problem still persists.