1
<html><head><title>Preventing brute force attacks using iptables recent matching</title></head><body>
3
<h1>Preventing brute force attacks using iptables recent matching</h1>
7
In recent times our network has seen a lot of attempts to brute-force ssh
8
passwords. A method to hamper such attacks by blocking attacker's IP
9
addresses using iptables 'recent' matching is presented in this text:
12
If the amount of connection attempts from a certain IP address exceeds a
13
defined threshold, this remote host is blacklisted and further incoming
14
connection attempts are ignored. The host is only removed from the blacklist
15
after it has been stopped connecting for a certain time.
18
<h2>Software requirements</h2>
20
<a href="http://www.kernel.org/">Linux kernel</a> and <a href="http://www.netfilter.org/">iptables</a> with 'recent' patch.
24
<em>It seems like this patch has entered the mainline some time ago. 'Recent'
25
matching e.g. is known to be included with kernels 2.4.31 and 2.6.8 of <a href="http://www.debian.org/">Debian</a> <a href="http://www.debian.org/releases/stable/">stable</a> ('sarge').</em>
30
</p><h2>Implementation</h2>
32
We begin with empty tables...
35
...and add all the chains that we will use:
40
<h3>Setup <tt>blacklist</tt> chain</h3>
42
One chain to add the remote host to the blacklist, dropping the connection attempt:
43
</p><pre>iptables -A blacklist -m recent --name blacklist --set
44
iptables -A blacklist -j DROP
46
The <em>duration</em> that the host is blacklisted is controlled by the match in the <tt>ssh</tt> chain.
51
<h3>Setup <tt>ssh</tt> chain</h3>
54
In the <tt>ssh</tt> chain, incoming connections from blacklisted hosts are
55
dropped. The use of <tt>--update</tt> implies that the timer for the duration
56
of blacklisting (600 seconds) is restarted every time an offending packet is
57
registered. (If this behaviour is not desired, <tt>--rcheck</tt> may be used
60
</p><pre>iptables -A ssh -m recent --update --name blacklist --seconds 600 --hitcount 1 -j DROP
63
These rules are just for counting of incoming connections.
65
<pre>iptables -A ssh -m recent --set --name counting1
66
iptables -A ssh -m recent --set --name counting2
67
iptables -A ssh -m recent --set --name counting3
68
iptables -A ssh -m recent --set --name counting4
71
With the following rules, blacklisting is controlled using several rate
72
limits. In this example, a host is blacklisted if it exceeds 2 connection
73
attempts in 20 seconds, 14 in 200 seconds, 79 in 2000 seconds or 399 attempts
76
<pre>iptables -A ssh -m recent --update --name counting1 --seconds 20 --hitcount 3 -j blacklist
77
iptables -A ssh -m recent --update --name counting2 --seconds 200 --hitcount 15 -j blacklist
78
iptables -A ssh -m recent --update --name counting3 --seconds 2000 --hitcount 80 -j blacklist
79
iptables -A ssh -m recent --update --name counting4 --seconds 20000 --hitcount 400 -j blacklist
82
The connection attempts that have survived this scrutiny are accepted:
83
<pre>iptables -A ssh -j ACCEPT
89
<h3>Setup INPUT chain</h3>
90
Allow packets that belong to existing connections:
91
<pre>iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
93
Allow all packets from loopback interface:
94
<pre>iptables -A INPUT -i lo -j ACCEPT
97
Optionally we may allow all packets from certain friendly subnets. However
98
this should be used sparingly and it should be kept in mind that hosts from
99
friendly subnets may be compromised and out of a sudden be not so friendly
102
<pre>iptables -A INPUT -s aa.bb.cc.0/24 -j ACCEPT
105
Now we direct all incoming ssh connections to the chain of the same name:
106
<pre>iptables -A INPUT -p TCP --dport ssh -m state --state NEW -j ssh
109
What remains in this chain has no right to continue:
110
<pre>iptables -A INPUT -j DROP
117
<li>Depending on personal taste, the check against the blacklist (first rule
118
of <tt>ssh</tt> chain) might be moved to the top of the <tt>INPUT</tt> chain
119
so that all communication (not only subsequent connection attempts) from the
120
blacklisted host is blocked immedeately.</li>
122
<li>Many other packet matching criteria might be conceived that would
123
warrant putting the sender on the blacklist.</li>
125
<li>Identical or similar effects possibly may be achieved using different
126
extensions to iptables.</li>
132
<h3>Denial of Service</h3>
134
Theoretically, the described approach opens a DoS vulnerability, that may be
135
exploited using SYN-packets with fake sender address to disable ssh
136
connections from a certain host. Therefore 'recent' matching should not be
137
used, when the ability to connect to the machine from any location and at all
138
times is mission-critical. When it is not, the problem of DoS may be
139
addressed when it happens, which probably is never.
142
Also it should be mentioned, that the ssh daemon itself in its current
143
implementation is vulnerable to DoS: There is an upper value for concurrent
147
<h3>No substitute for secure passwords</h3>
149
The approach described here by no means is a substitute for using secure
150
passwords that are difficult to guess and to brute-force! Disabling root
151
logins in sshd is very much recommended! (Oh, by the way: There is also an
152
option to disallow empty passwords for sshd. ;-)
155
<h3>Security by Obscurity</h3>
157
It should be noted that this scheme <em>partly</em> employs methods of
158
'security by obscurity' to increase its effectivity. A casual attacker
159
probably will be blocked for a long time (possibly forever) after serveral
160
tries. Yet a determined, observant attacker still may try passwords at the
161
rate specified by the <tt>counting4</tt> rule. However this is still a
162
considerable improvement compared to no limit at all.
165
Often 'security by obscurity' is frowned upon as offering 'no real' security.
166
Yet, such an opinion is undifferentiated. It may be very well true that
167
secrecy does not increase the hardness of the system with respect to 'the most
168
elaborate attack' that still will be averted. However for sure it is well
169
suited to stall casual attacks and by such reduce the overall number of
170
attacks. Seen in this light, it might also be sensible to use a non-standard
171
port for ssh service.
174
<h2>Further Reading</h2>
176
<li><a href="http://snowman.net/projects/ipt_recent/">Iptables recent patch web site</a></li>
177
<li><a href="http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO.html">Netfilter Extensions HOWTO</a></li>
180
<h2>About this document</h2>
182
These are some random scribblings prepared for a meeting of sysadmins at <a href="http://www.tum.de/">TUM</a> <a href="http://www.physik.tu-muenchen.de/">Physik-Department</a>. The concept
183
was motivated by <a href="http://e18.physik.tu-muenchen.de/%7Erkuhn/">Roland Kuhn</a>. The author of this text
184
is Thiemo Nagel. Please send comments to <em>tnagel at
185
e18.physik.tu-muenchen.de</em>.
b'\\ No newline at end of file'