Block troublemakers using fail2ban

I don't mind running my own virtual servers. Fail2ban is a tool I've had running on my servers for years. It helps fencing of requests from ip-addresses that repeatedly misbehave when connecting to SSH and postfix. I never got to creating my own rules. I thought I had to write it in some arcane scripting language, but recently I learned it is pretty easy.

In this case I wanted to block 500 (internal server error) and 422 (Unprocessable Entity) errors. A server error once in a while is expected, but repeated server errors are suspicious. Common source of these errors are scripts that scan for things like SQL injections.

Examples given are for Debian.

/etc/fail2ban/filter.d/nginx-errors.conf

[Definition]

failregex = ^ -.*"(GET|POST|HEAD).*HTTP.*" (500|422)
port = http,https
ignoreregex =
backend = auto
logpath = /var/log/nginx/access.log
bantime = 600
maxretry = 10

And appending to /etc/fail2ban/jail.local…

A somewhat secure Debian server with nginx, Passenger, rbenv for hosting Ruby on Rails with mail support and deployment with Capistrano

Basically this is a technical note to myself, in case I need to setup another server for running yet another personal Ruby on Rails project. And don't worry, I'm not going to replicate all nice guides out there, just filling in the gaps.

So let's start with the list of bookmarks I follow as a start. Note that in these tutorials mostly a user is used named 'deploy'. Typically I create a user per project and name databases etc. accordingly.

1. Get security right first: My first 5 minutes on a server or essential security for Linux servers
2. Then I get Rails up and running with this how to install Ruby on Rails with rbenv on Debian
3. (in case you want to use the server as your remote git repo too) [Git setting up a remote repository and doing an inital push](http://the…

How to do it: Using screen

A technical note to myself: One way of doing multiple things simultanenously on a server can be by setting up multiple connections via SSH, that's how I used to do things before. An alternative is to use a single connection and use the command screen on the remote server. Another good reason to use screen is if you have a long running process that you don't want to break just because your SSH connection flips on and off with your computer going in and out of stand-by.

This is for absolute beginners. If you don't know about screen, this is for you. If you are already familiar with screen, I probably won't be able to educate you :o

So what is Screen?

GNU Screen is a kind of window managment system for the terminal (you're ought to say terminal multiplexer) and has several advantages over using multiple SSH connections. Most importantly: the processes keep running when SSH d…