1 |
On Thursday 04 December 2008 21:03:17 Christian Franke wrote: |
2 |
> On 12/03/2008 09:02 PM, Steve wrote: |
3 |
> > I've recently discovered a curious pattern emerging in my system log |
4 |
> > with failed login attempts via ssh. |
5 |
> > |
6 |
> > I'm not particularly concerned - since I'm confident that all my users |
7 |
> > have strong passwords... but it strikes me that this data identifies a |
8 |
> > bot-net that is clearly malicious attempting to break passwords. |
9 |
> > |
10 |
> > Sure, I could use IPtables to block all these bad ports... or... I could |
11 |
> > disable password authentication entirely... but I keep thinking that |
12 |
> > there has to be something better I can do... any suggestions? Is there |
13 |
> > a simple way to integrate a block-list of known-compromised hosts into |
14 |
> > IPtables - rather like my postfix is configured to drop connections from |
15 |
> > known spam sources from the sbl-xbl.spamhaus.org DNS block list, for |
16 |
> > example. |
17 |
> |
18 |
> I just don't see what blocking ssh-bruteforce attempts should be good |
19 |
> for, at least on a server where few _users_ are active. |
20 |
|
21 |
Two reasons: |
22 |
|
23 |
a. Maybe, just maybe, you overlooked something. Belts, braces and a drawstring |
24 |
for good measure is not a bad thing. |
25 |
|
26 |
b. You probably want to get all that crap out of your log files off into some |
27 |
other place where you can cope with it. Parsing auth log files that are 95% |
28 |
brute force attempts is no fun. I like to have the crap in place A and the |
29 |
real stuff in place B, makes my job so much easier |
30 |
> |
31 |
> The chance that security of a well configured system will be compromised |
32 |
> by that is next to zero, and on recent systems it is also impossible to |
33 |
> cause significant load with ssh-login-attempts. |
34 |
|
35 |
Uh-huh. We all said that for many years. Then some bright spark actually |
36 |
looked at the patches the debian openssh maintainer was applying and we all |
37 |
had one of those special "oops..." moments |
38 |
|
39 |
Did you have any idea of just how weak certs made on a debian box were before |
40 |
it hit the headlines? No-one I know did. |
41 |
|
42 |
> Also, things like fail2ban add new attack-possibilities to a system, I |
43 |
> remember the old DoS for fail2ban, resulting from a wrong regex in log |
44 |
> file parsing, but I think at least this is fixed now. |
45 |
|
46 |
Whereas that is true enough in itself, the actual risk of such is rather low |
47 |
in comparison to the gains. Hence it is not a valid reason to not use |
48 |
fail2ban and such-like apps. |
49 |
|
50 |
If it were, we should all just stop using iptables and libwrap and openssl on |
51 |
the off-chance that maybe, just maybe, they open an attack vector. But that's |
52 |
silly reasoning right? |
53 |
|
54 |
|
55 |
-- |
56 |
alan dot mckinnon at gmail dot com |