/docs/MyDocs

To get this branch, use:
bzr branch http://darksoft.org/webbzr/docs/MyDocs

« back to all changes in this revision

Viewing changes to Administration/Server/Network/routing/Preventing brute force attacks using iptables recent matching.html

  • Committer: Suren A. Chilingaryan
  • Date: 2017-04-03 02:45:17 UTC
  • Revision ID: csa@suren.me-20170403024517-dwzj0z0k1cmhxm7u
Restructuring, OpenShift, Ansible, Git

Show diffs side-by-side

added added

removed removed

Lines of Context:
Administration/Server/Network/routing/Preventing brute force attacks using iptables recent matching.html
 
1
<html><head><title>Preventing brute force attacks using iptables recent matching</title></head><body>
 
2
 
 
3
<h1>Preventing brute force attacks using iptables recent matching</h1>
 
4
 
 
5
<h2>General idea</h2>
 
6
<p>
 
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:
 
10
</p>
 
11
<p>
 
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.
 
16
</p>
 
17
 
 
18
<h2>Software requirements</h2>
 
19
<p>
 
20
<a href="http://www.kernel.org/">Linux kernel</a> and <a href="http://www.netfilter.org/">iptables</a> with 'recent' patch.
 
21
</p>
 
22
 
 
23
<p>
 
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>
 
26
</p>
 
27
 
 
28
 
 
29
<p>
 
30
</p><h2>Implementation</h2>
 
31
<p>
 
32
We begin with empty tables...
 
33
</p><pre>iptables -F
 
34
</pre>
 
35
...and add all the chains that we will use:
 
36
<pre>iptables -N ssh
 
37
iptables -N blacklist
 
38
</pre>
 
39
 
 
40
<h3>Setup <tt>blacklist</tt> chain</h3>
 
41
<p>
 
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
 
45
</pre>
 
46
The <em>duration</em> that the host is blacklisted is controlled by the match in the <tt>ssh</tt> chain.
 
47
<p></p>
 
48
 
 
49
 
 
50
 
 
51
<h3>Setup <tt>ssh</tt> chain</h3>
 
52
 
 
53
<p>
 
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
 
58
instead.)
 
59
 
 
60
</p><pre>iptables -A ssh -m recent --update --name blacklist --seconds   600 --hitcount   1 -j DROP
 
61
</pre>
 
62
 
 
63
These rules are just for counting of incoming connections.
 
64
 
 
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
 
69
</pre>
 
70
 
 
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
 
74
in 20000 seconds.
 
75
 
 
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
 
80
</pre>
 
81
 
 
82
The connection attempts that have survived this scrutiny are accepted:
 
83
<pre>iptables -A ssh -j ACCEPT
 
84
</pre>
 
85
<p></p>
 
86
 
 
87
 
 
88
 
 
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
 
92
</pre>
 
93
Allow all packets from loopback interface:
 
94
<pre>iptables -A INPUT -i lo -j ACCEPT
 
95
</pre>
 
96
 
 
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
 
100
anymore...
 
101
 
 
102
<pre>iptables -A INPUT -s aa.bb.cc.0/24 -j ACCEPT
 
103
</pre>
 
104
 
 
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
 
107
</pre>
 
108
 
 
109
What remains in this chain has no right to continue:
 
110
<pre>iptables -A INPUT -j DROP
 
111
</pre>
 
112
 
 
113
 
 
114
<h3>Variations</h3>
 
115
<ul>
 
116
 
 
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>
 
121
 
 
122
<li>Many other packet matching criteria might be conceived that would
 
123
warrant putting the sender on the blacklist.</li>
 
124
 
 
125
<li>Identical or similar effects possibly may be achieved using different
 
126
extensions to iptables.</li>
 
127
 
 
128
</ul>
 
129
 
 
130
 
 
131
<h2>Limitations</h2>
 
132
<h3>Denial of Service</h3>
 
133
<p>
 
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.
 
140
</p>
 
141
<p>
 
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
 
144
connections.
 
145
</p>
 
146
 
 
147
<h3>No substitute for secure passwords</h3>
 
148
<p>
 
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. ;-)
 
153
</p>
 
154
 
 
155
<h3>Security by Obscurity</h3>
 
156
<p>
 
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.
 
163
</p>
 
164
<p>
 
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.
 
172
</p>
 
173
 
 
174
<h2>Further Reading</h2>
 
175
<ul>
 
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>
 
178
</ul>
 
179
 
 
180
<h2>About this document</h2>
 
181
<p>
 
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>.
 
186
</p>
 
187
 
 
188
</body></html>
 
 
b'\\ No newline at end of file'