Taking a look at the logwatch mails I see a common pattern of attacks, coming from China and trying to find details of my server configuration, which is something I dont like.

Looking around I found fail2ban which is a tool that does som regex matches on the server logs (sshd, httpd, authd, …) and takes proper actions, like banning the offending IP.

I then installed fail2ban in my Debian box:

> apt-get install fail2ban

Then, I took a look at /etc/fail2ban/jail.conf and found some entries for Apache but none for nginx, my server of choice, so I decided to create a jail.local to add some nginx stuff (this is recommended in Debian to allow hassle-free upgrades).

I started copying the Apache sections of the default fail2ban as the log files in my case use the same format that allows me to use Awstats easily. Then, I modified my log routes to point to the nginx ones and using Apache rules, if they don’t work I’ll tune them later.

[nginx]

enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/log/nginx*/*error.log
maxretry = 6

[nginx-noscript]

enabled = false
port    = http,https
filter  = apache-noscript
logpath = /var/log/nginx*/*error.log
maxretry = 6

[nginx-overflows]

enabled = false
port    = http,https
filter  = apache-overflows
logpath = /var/log/nginx*/*error.log
maxretry = 2

Although this is ok, the bots I see don’t leave a trace in error.log but in access.log so I took a look at the filter.d folder where an interesting apache-badbots.conf was present. Then, I found the default fail2ban documentation in /usr/share/doc/fail2ban where there’s an usage example of the badbots script. I added I to my jail.local:

[apache-badbots]

enabled  = true
port    = http,http
filter   = apache-badbots
logpath  = /var/log/nginx*/*access.log
bantime  = 172800
maxretry = 1

Finally, I added this to the top of the file, to send mails to myself when a rule matches and a host is banned.

[DEFAULT]

action = %(action_mwl)s

Finally, restart the service and start receiving mails:

> sudo /etc/init.d/fail2ban restart

I’m sure this will need further adjustments, but it’s a beginning in my bot fighting war. I’ll make some updates as I find interesting results.

This summer Dreamhost launched their 50Gb backup account which was great news but unfortunately they only offered FTP access. In the October newsletter they announced rsync and SCP support for the backup user using RSSH and I will now show you how to set up an automatic script to back your valuable data up. That is quite cool, so don’t hesitate to sign-up with them and try out this feature.

The first thing is configuring the account for SCP/SFTP/rsync access. Go to the Backups User section of the Users menu in the Panel and create a user. They’ll give you a name and a password and send you an email with all the information. That’s the only thing you need.

Then, you must create the folder structure to hold your backups in case you don’t want to have everything on the root folder. The easiest thing is to get a SFTP client. In my case I used WinSCP, but you can use whatever you want. I created a folder called photos to hold my digital collection.

Now, the trickiest part. If you have a modern Linux distribution or any up to date rsync compilation it’s very possible that you have version 3.0 or later that implements protocol version 30. To know the version of rsync, just write:

rsync --version

In my case, I have “rsync  version 3.0.3  protocol version 30″. In that case, if you use rsync as usual, you’ll get a nice error saying that:

insecure -e option not allowed.
This account is restricted by rssh.
Allowed commands: scp sftp rsync

After googling a little, I discovered that protocol 30 sends implicitly an -e command and the installed version in Dreamhost does not like that, because it uses protocol 29. The solution is adding ‘–protocol 29′ to the rsync options.

Then, to make the whole process automatic, you need to avoid rsync asking for a password. That can be easily done following this instructions on passwordless ssh. Note that you can’t ssh to the remote machine but if you create a new file called authorized_keys locally with the contents of id_dsa.pub and then using the SFTP client upload it to a new folder (if not exists) called .ssh (don’t forget the dot!). It will work like a charm.

Then, create a script that does the rsync thing. In my case, I have this single instruction, but you can sync as many folders as you want.

rsync -aP --delete --protocol=29 /mnt/photos/* bXXXXXXX@backup.dreamhost.com:photos

With this, I tell rsync to use archive mode (-a), which is quite interesting as it preserves timestamps and is recursive, and to store partial information (-P) in case I break the connection. Then I tell rsync to delete the destination files that are not in the source (which can be dangerous if you delete something locally and want to recover it later, so I leave this option up to you). Then to use protocol version 29 (–protocol 29) as I discussed earlier. Finally, I tell rsync which is the source folder and the destination one, indicating the username and the host.

And that’s it. If you store this command in a .sh file and put it in the crontab (with crontab -e), you can automatically back up your valuable data to the Dreamhost backup account. My crontab settings are like this:

# m h  dom mon dow   command
0 2 * * * ~/backup.sh > ~/backup.log

This will execute the backup script every day at 2 AM, and will store a .log, in case I want to check the results. Note that the first time that you execute the script it may take some time (4 days for me, 18Gb in total) depending on the amount of data to back up, so I recommend you to execute it manually before creating an automatic task.

Finally, I want to remind you that the data stored in that account is not guaranteed by any means by Dreamhost, so don’t make it your only full trusted source for backup data.

Link | Dreamhost

Note: This is my first post in English, so please forgive my errors, I tried my best.