One thing that comes with the territory when running servers (application servers or otherwise) is the continual and incessant attacks and intrusion attempts that occur. Most of these are simply querying your server looking for older versions of server applications to exploit (I'm looking at you myphpadmin and wordpress...).
I've spent quite some time consistently monitoring access logs and understanding the various patterns malicious entities use when scanning for exploits. I find it very interesting (please tell me others other people sometimes just 'less +F' watch their apache logs while eating lunch...) and have noticed some interesting trends approaches here.
Anyways, once I understand the general attack approaches particular to my servers, I usually implement something like the excellent fail2ban to automagically (perma?)ban ip addresses. It always makes me smile when I see these requests hit my server and then see the (virtual) ban hammer drop on them 
.
...
| Table of Contents | ||
|---|---|---|
|
Guide
Installing fail2ban and ipset
Let's now install fail2ban on our server. It's in most (if not all) distro package managers.
...
NOTE: this assumes you have the required python packages installed, as outlined here.
We'll also need ipset installed. See my guide here for directions on doing this.
Next, we're going to install ipset to manage the blocking on ip addresses.
On Debian/Ubuntu we can do:
| Code Block | ||
|---|---|---|
| ||
sudo apt-get install ipset |
On CentOS/Amazon-Linux you would do:
| Code Block | ||
|---|---|---|
| ||
sudo yum install ipset |
Configuration with clean jail.local and apache-custom filter
...
A few notes here. Add your own ip addresses or ip address range (CIDR) to ignore in this line. For example 10.0.0.0/24 will ignore 10.0.0.0 and ip range [10.0.0.1 - 10.0.0.254255] which is an internal network ip range.
...
Now, testing to verify that our apache-custom filter is working is extremely important. Regular expressions are very easy to mess up. Fail2ban comes with some nice tools that we can use to test our filter. We first need something to test against. I like to keep a log with actual (attack) requests to my server. Whenever I find a new pattern that I want to ban, I add an example of the actual request to a samples.log file. For example, here is one which has actual requests to my server (and the actual ip addresses they came from - wo unto the ip addresses below, I hereby publicly shame thee!):
| View Git file | ||||||
|---|---|---|---|---|---|---|
|
...
| Code Block | ||
|---|---|---|
| ||
sudo chkconfig fail2ban on sudo service fail2ban start |
Manually adding / removing ip (or ip ranges)
You might need (or want) to add an ip address to fail2ban manually from time to time. You can use the fail2ban-client commands for this:
manully add ip to a fail2ban jail
| Code Block |
|---|
sudo fail2ban-client set apache-custom banip <IP-ADDRESS> |
manually remove ip (or CIDR) to a fail2ban jail
| Code Block |
|---|
sudo fail2ban-client set apache-custom unbanip <IP-ADDRESS> |
| Info |
|---|
Replace |
To DB or not to DB...
Fail2ban 0.9 introduced an integrated SQLite database for bans. This means that on restarting (fail2ban or your server) the previously banned ip addresses will be rebanned (instead of being lost). Although this is a great feature, I've found it does have some downsides - such as taking a lot of time to shutdown and startup fail2ban. On one of my servers, with approximately 6000 banned ips - shutting down fail2ban would take 5 minutes or so, and starting it back up would take around 10 minutes as it (one by one) rebanned each banned ip from the database.
...