Monthly Archives: June 2009

Nginx rewrite rules for SilverStripe CMS

Posted on by
2

If you are using Nginx with a configuration that is directly serving php pages via FastCGI, you need to adapt the rewrite rules to Nginx. In the case of the CMS-system SilverStripe this is not really straight forward. The original rewrite definition in the .htaccess file looks like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
 
RewriteCond %{REQUEST_URI} !(\.gif)|(\.jpg)|(\.png)|(\.css)|(\.js)|(\.php)$
 
RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* sapphire/main.php?url=%1&%{QUERY_STRING} [L]
</IfModule>

So every file which does not end in .gif, .jpg, .png, .css, .js and .php and where the file does not exist will be rewritten.

I chose a somehow stripped down version of these rules which looks in Nginx notation like this:

if (!-f $request_filename) {
    rewrite ^/(.*?)(\?|$)(.*)$ /sapphire/main.php?url=$1&$3 last;
}

If a requested file is not found, the rewriting engine will parse the request string for all elements before a ‘?’. This substring will be pasted as the url parameter to main.php. Everything after ‘?’ will be added as additional parameters. This rewrite rule seems to be working and I haven’t encountered any problems so far.

Securing SSH server with fail2ban

Posted on by
4

When you are running your SSH server on the standard port 22, you likely see brute force login attempts multiple times a day. The SSH server does not limit unsuccessfull login attempts by itself. So there are multiple ways to deal with this problem.

One option is to move the SSH daemon to a non-standard port. But this means that you might get problems connecting yourself to the server if you are working from a restricted network. So another solution would be to use certificates for login. But then you need to make sure that you carry the certificates with you when you want to login to your server.

Now a good solution is to limit access to the SSH server. One way would be to use the so called port-knocking approach. Here the access to the SSH port is blocked until you use some kind of secret knock-sequence. Then the port will be unblocked for your IP for a certain time. This is very effective but has the downside that you always need to use this knock mechanism before connecting to your server.

Continue reading →