When you have a server on the Internet, you get lots of "brute force"
attacks on the SSH daemon, trying plausible logins with a variety of
passwords. Even with good passwords, these attacks might eventually
succeed (and they're annoying even when they don't), so you want to
thwart them.
One way is to use
fail2ban, a script that monitors the failed
connections, and sets up firewall rules (for instance) blocking
further connections from the attacking IP addresses. It's good, but
it fills your logs with messages about IPs getting banned and unbanned
after a while. And you're still at risk that the multiple connections
crash the SSH daemon, or trigger a bug in it, or whatever.
A second layer of protection can be to block all SSH connection
attempts except when they come from known IP addresses, but that
doesn't work when you're away from home, and you're locked out. Been
there, done that.
So, some wise people have devised a trick called "port-knocking".
It's similar to only opening the door to people who use a special
knock (think "That's all, folks"): the firewall stays closed, but it
opens a tiny targeted hole to some IP addresses for a limited length
of time, based on a secret handshake. The window for attack is
therefore very small, and the SSH daemon stays idle most of the time.
And you can still log on your hosted server when you're attending
conferences. There are a variety of implementations for this concept.
Some could be web-based (you need to submit the right password to a
web page), some could use other services or a dedicated daemon.
But when I started investigating port-knocking, I wanted something
simple, preferably with no dependencies on a daemon that would need to
be exposed to the net and potentially crash. I found
an
article on the
Debian Administration
website, but I wasn't entirely satisfied with it. The principles
appealed to me (netfilter-only, secret handshake in the form of
opening connections to secret ports), though, so I evolved it into my
own implementation, which I proudly present to you today.
The goals of this implementation were:
- flexibility;
- robustness;
- resistance to replay attacks;
- no dependency on user-land daemons;
- simple, easily auditable code;
- must not be a pain in the neck to use.
The bulk of the work therefore stays in the kernel's netfilter (that's
for robustness and no user-land dependency), but the control interface
is integrated with the usual firewalling script.
Resistance to replay attacks is achieved by choosing hard-to-predict
ports. So if someone snoops the wireless while I'm at a conference
and catches my secret handshake, it'll only be valid for a short
period of time, hopefully short enough to prevent dictionary attacks.
The handshake is therefore calculated as a function of the current
date and time, with an added secret seed. The following shell
function calculates 5 port numbers within a given range (requires
dc
to be installed, for big-integer arithmetic):
calc_knock_ports ()
secret=$1
bottomport=$2
topport=$3
nbports=$(( $topport - $bottomport + 1 ))
hash=$(TZ=UTC date +%Y-%m-%d-%H-$secret md5sum awk ' print $1 ' tr a-z A-Z)
num=$(echo 16i $hash f dc)
pk_port1=$(echo $num $nbports 0 ^ / $nbports % $bottomport + f dc)
pk_port2=$(echo $num $nbports 1 ^ / $nbports % $bottomport + f dc)
pk_port3=$(echo $num $nbports 2 ^ / $nbports % $bottomport + f dc)
pk_port4=$(echo $num $nbports 3 ^ / $nbports % $bottomport + f dc)
pk_port5=$(echo $num $nbports 4 ^ / $nbports % $bottomport + f dc)
Okay. So this function calculates ports, now what? Now we're going
to define a few chains by which netfilter will store states of IP
addresses as they progress through the handshake:
setup_portknocking_tables ()
iptables -N portknock_into_phase1
iptables -A portknock_into_phase1 -m recent --name PK_PHASE1 --set
# iptables -A portknock_into_phase1 -j LOG --log-level notice --log-prefix "INTO PK_PHASE1: "
iptables -N portknock_into_phase2
iptables -A portknock_into_phase2 -m recent --name PK_PHASE1 --remove
iptables -A portknock_into_phase2 -m recent --name PK_PHASE2 --set
# iptables -A portknock_into_phase2 -j LOG --log-level notice --log-prefix "INTO PK_PHASE2: "
iptables -N portknock_into_phase3
iptables -A portknock_into_phase3 -m recent --name PK_PHASE2 --remove
iptables -A portknock_into_phase3 -m recent --name PK_PHASE3 --set
# iptables -A portknock_into_phase3 -j LOG --log-level notice --log-prefix "INTO PK_PHASE3: "
iptables -N portknock_into_phase4
iptables -A portknock_into_phase4 -m recent --name PK_PHASE3 --remove
iptables -A portknock_into_phase4 -m recent --name PK_PHASE4 --set
# iptables -A portknock_into_phase4 -j LOG --log-level notice --log-prefix "INTO PK_PHASE4: "
iptables -N portknock_into_phase5
iptables -A portknock_into_phase5 -m recent --name PK_PHASE4 --remove
iptables -A portknock_into_phase5 -m recent --name PK_PHASE5 --set
iptables -A portknock_into_phase5 -m recent --name PK_ESTABLISHED --set
# iptables -A portknock_into_phase5 -j LOG --log-level notice --log-prefix "INTO PK_PHASE5: "
iptables -N portknock_accept
iptables -A portknock_accept -m limit -j LOG --log-level notice --log-prefix "ACCEPTED AFTER PORTKNOCKING: "
# iptables -A portknock_accept -m recent --name PK_PHASE5 --remove
iptables -A portknock_accept -j ACCEPT
iptables -N portknocking
These chains use the
recent module, which seems to be commonly
available in standard kernels. You'll notice how, as one packet goes
through these rules, its originating IP address moves from one set of
"recent" addresses to the next. But no logic exists yet to make the
packet actually go through these rules, so here comes the glue:
refresh_portknocking ()
calc_knock_ports f00b4r 10000 10999
iptables -F portknocking
iptables -A portknocking -p tcp --dport $pk_port1 -m state --state NEW -j portknock_into_phase1
iptables -A portknocking -p tcp --dport $pk_port2 -m state --state NEW -m recent --rcheck --name PK_PHASE1 --seconds 5 -j portknock_into_phase2
iptables -A portknocking -p tcp --dport $pk_port3 -m state --state NEW -m recent --rcheck --name PK_PHASE2 --seconds 5 -j portknock_into_phase3
iptables -A portknocking -p tcp --dport $pk_port4 -m state --state NEW -m recent --rcheck --name PK_PHASE3 --seconds 5 -j portknock_into_phase4
iptables -A portknocking -p tcp --dport $pk_port5 -m state --state NEW -m recent --rcheck --name PK_PHASE4 --seconds 5 -j portknock_into_phase5
# echo clear > /proc/net/ipt_recent/PK_DONE
echo clear > /proc/net/ipt_recent/PK_PHASE1
echo clear > /proc/net/ipt_recent/PK_PHASE2
echo clear > /proc/net/ipt_recent/PK_PHASE3
echo clear > /proc/net/ipt_recent/PK_PHASE4
echo clear > /proc/net/ipt_recent/PK_PHASE5
Right. This function adds rules to the
portknocking chain. A
packet injected into this ruleset will, depending on its destination
port and whether its source IP address has already been seen, end up
in one of the PK_PHASE* sets. All we have to do now is therefore to
send some packets to this
portknocking chain, and use the
port-knocking sets to decide whether to accept incoming connections or
not:
iptables -A INPUT -j portknocking
iptables -A INPUT -m recent --rcheck --seconds 5 --name PK_PHASE5 -m state --state NEW -p tcp --dport ssh -j portknock_accept
This example only mentions accepting incoming SSH connections, but
it's in no way a limitation: a server of mine uses similar rules to
DNAT certain ports to internal IP addresses.
And there we have it for the server part: incoming SSH connections are
usually ignored (well, handled by the rest of the firewall script, but
let's assume that it drops these packets by default), but if one IP
address knows the appropriate ports and sends a connection attempt to
them in order, then it'll be able to open SSH connections for a little
while after that. Of course, it's going to be boring if one has to
send these packets by hand, but it can be easily automated by a
script. Here's a
~/bin/portknock.sh I have:
#! /bin/sh
host=$1
port=$2
calc_knock_ports ()
[...]
calc_knock_ports f00b4r 10000 10999
for i in $pk_port1 $pk_port2 $pk_port3 $pk_port4 $pk_port5 ; do
nc -w 1 $host $i < /dev/null > /dev/null 2>&1
done
nc $host $port
It's designed to be called with two parameters, a host and a port, and
it needs
netcat in addition to
dc. Why the last line, I hear you
cry? Because then I can just add the following lines to my
~/.ssh/config:
Host blahblah
IdentityFile foobar
ProxyCommand /home/roland/bin/portknock.sh %h %p
...and SSH will automagically tunnel its network socket through the
script, which will in turn happily tunnel that through
netcat after
completing the secret handshake.
And when I type
ssh myserver on my laptop, interesting stuff happens
behind the scenes, and a special, just-for-me hole is opened in the
server firewall, just for the few seconds I need to establish the SSH
session (packets belonging to established TCP sockets are allowed by
the firewall's connection tracking).
Note: This article is deliberately short on details and
ready-to-run scripts. Firstly because firewall scripts vary wildly so
any script would have to be adapted anyway, but mostly because
security is best handled with one's brain switched on. Fiddling with
a firewall can easily open gaping holes or lock everyone out. So
please make sure you understand what goes on before blindly pasting
stuff into your own setup. Some of the lines that are commented out
may also be of interest, and were left as an exercise for the reader.
Other lines were not included, and are also left as a rather important
exercise to the reader; note in particular how the netfilter rules as
currently established do not mitigate the replay attacks...
I tried terminator (thanks go to Nicolas Valcarcel for asking me to sponsor a Debian upload, thus forcing me to try it, and Asheesh Laroia for doing a lightning talk at debconf about it), but I’m not convinced.
I got back home from DebConf8 about 11pm last night, having left Mar del Plata at 11am on Sunday morning. 4 hours time difference makes for a 32 hour trip time covering minibus, 2 planes, a coach and a car, 3 time zones (I flew via Madrid) and 4 countries. Not fun, and I'm glad I booked today off to recover. However I'm also exceptionally glad I went to what's probably my best DebConf so far.
While I enjoyed watching some of the 
What I liked
.
Sound Juicer "I Don't Know What You Heard But It's Mandatory" 2.23.2 has been
released. Tarballs are
available 
This talk will briefly explain what Debian Edu is, how we develop our distribution, how we differ from Debian, how we work on bridging the gaps that still exist and what our plans for the future are.
I’ve been playing with a blacklight here at Debconf, during the keysigning party. (Hey, I’m a geek; what did you expect.) Of course, I cannot resist sharing what I saw:
Some time ago, when I packaged 
Missed the morning talks.. looking forward to replays being available..
rails
Projects not bothering to release tarballs, and just publishing a git repo
(hopefully with some tags!) will only become more common, I think, and it's
interesting to see this is already very common with ruby gems.
Faking up an orig tarball is still a reasonable workaround now, but will
probably look very retro in 5 years.
Re Debian vs Rails communities, I wonder if there's a generation gap in here
somewhere..
rest
(will update throughout the day)
po4a - or PO for anything. PO is the de facto standard for translations and po4a tries to help maintainers prepare packages for translation.
