Martín Ferrari: Setting up my server: netfilter
I was going to start this series with explaining how I did the remote set-up, but instead I will share something that happened today.
One of the first things you want to do when putting a server directly connected to the Internet is some filtering. You don't want to have an application listening on the network by mistake, so a simple netfilter firewall is a good way to ensure you are only accepting connections on ports you explicitly allowed.
I have been a long-time user of ferm, a simple tool that will read a configuration file written in a special structured syntax, and generates iptables commands from it. I have used it successfully to build very complex firewalls in previous jobs, and it had the huge benefit of keeping your firewall description readable and easy to modify by other people.
This time I thought I may go with something simpler, as I only wanted a handful of very simple netfilter rules. I looked at Shorewall, and browsed a bit a few others. But in the end I decided against them: there was the need to learn the tools' concepts about different parts of the network, or there were more slanted towards command-line commands, so your actual configuration will be some files in /var/lib, totally managed by the tool. With ferm, I just need to write a very small configuration file, which reads almost like iptables commands, and that's it.
In fact, the default configuration placed by the Debian package, already did 90% of what I wanted: accept incoming SSH connections, ICMP packets, and reject everything else. I took the example IPv6 configuration from /usr/share/doc/ferm/examples/ipv6.ferm and in 10 minutes it was ready:
table filter
chain INPUT
policy DROP;
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
interface lo ACCEPT;
proto icmp ACCEPT;
# allow IPsec
proto udp dport 500 ACCEPT;
proto (esp ah) ACCEPT;
proto tcp dport ssh ACCEPT;
proto tcp dport (http https) ACCEPT;
chain OUTPUT policy ACCEPT;
chain FORWARD policy DROP;
domain ip6 table filter
chain INPUT
policy DROP;
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
interface lo ACCEPT;
proto ipv6-icmp ACCEPT;
proto tcp dport ssh ACCEPT;
proto tcp dport (http https) ACCEPT;
chain OUTPUT policy ACCEPT;
chain FORWARD policy DROP;
at job to disable the firewall in a few minutes:
# echo /etc/init.d/ferm stop at now +10min
warning: commands will be executed using /bin/sh
job 4 at Mon Apr 29 02:47:00 2013
# atrm 4
--interactive mode which will revert the changes if you get locked out, much like the screen resolution changing dialog in Gnome.
Another thing that you definitely want to do, is to have some kind of protection against the almost constant influx of brute-force attacks against SSH. Apart from the obvious
PermitRootLogin=no setting, there are a couple of popular methods to stop people probing random username/password combinations (I am assuming here that you actually have sensible passwords, or no passwords at all): running SSH in a non-standard port, and the great fail2ban daemon.
Since I don't like non-standard stuff, I installed fail2ban, which by default it will inspect /var/log/auth.log for SSH login failures and insert netfilter rules to block the offenders.
Problem is, I don't like much how fail2ban inserts rules and chains into my very tidy netfilter configuration which I had just created. So, I added an "action" to do things my way: only create a service-related chain and insert rules there, I will call that chain from my main ferm.conf. Ferm runs early in the boot sequence, so this won't be a problem during normal operation. The only caveat is that after changing a configuration in ferm, I need to restart fail2ban so it will recreate the netfilter chains and rules, which were wiped by ferm.
This is my configuration, note that I am ignoring the port and protocol: the whole IP is blocked for a few minutes.
# cat /etc/fail2ban/jail.local
[DEFAULT]
action = iptables-fixed[name=%(__name__)s]
# cat /etc/fail2ban/action.d/iptables-fixed.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -I fail2ban -j fail2ban-<name>
actionstop = iptables -D fail2ban -j fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
actioncheck = iptables -n -L grep -q fail2ban-<name>
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
[Init]
name = default
You might not know who Peter is because he s not very visible on Debian mailing lists. He s very active however and in particular on IRC. He was an admin of the OFTC IRC network at the time Debian switched from Freenode to OFTC. Nowadays he s a member of the Debian System Administration team who runs all the debian.org servers.
If you went to a Debconf you probably met him since he s always looking for new signatures of his GPG key. He owns the best connected key in the 
During that year I started getting involved in the German language
Debian channel on IRCnet which got me in contact with some DDs.
Christian Kurz (<shorty>) was working on Debian QA at the time
and he asked my help in writing a couple of scripts. Some of that
work, 
The svn repository used to draft the Debian Project News just passed the
sixth hundreds commit. If my calculations are correct, that's quite
more than the number of edits done, back when the DPN was drafted in the
wiki. I take it as a hint, that the new work flow works better than the
old one.
However, playing a bit with statistics (done by horrible shell one
liners ;)
I noticed, that - while every Debian Developer may commit to
the subversion repository - not that many commits from other DDs where
made: Of the 602 commits so far, only 70 where done by other DDs:
This post is to: