Date: Thu, 1 Oct 2015 12:49:35 -0400 From: Christopher Sean Hilton <chris@vindaloo.com> To: Ian Smith <smithi@nimnet.asn.au> Subject: Protecting sshd - Was: SSHguard & IPFW Message-ID: <20151001164935.GA1268@hadar.local> Resent-Message-ID: <20151001165054.GB1268@hadar.local> In-Reply-To: <20151001173313.T67283@sola.nimnet.asn.au> References: <mailman.98.1443614402.37653.freebsd-questions@freebsd.org> <20151001033001.R67283@sola.nimnet.asn.au> <CALf6cgY0TYxugyMWd7ugpL5YgjKYiX%2Bk35%2BP1%2BzwbDMJw9T2Jw@mail.gmail.com> <20151001173313.T67283@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 01, 2015 at 06:32:50PM +1000, Ian Smith wrote:
[ snip... ]
> Well I'm not as concerned about sshd vulnerabilities as I am about lots=
=20
> of superfluous logging from (usually) oft-repeated drive-by attempts on=
=20
> port 22, often across all 6 IPs of a /29. And yes, I prefer using port=
=20
> 22, despite the relief that using alternative ports does offer, mainly=20
> to keep things simple for users. This way, all other hosts attempting=20
> connections to port 22 simply vanish.
>=20
The way I see it, reducing the flood of log entries is where SSHguard
would shine but it can't really add a meaningful measure to your
overall security.
The crux of the issue is ssh with password auth. You are either
allowing passwords or you aren't. If you aren't allowing passwords
then the brute force industry chances of successfully compromising
your servers are very very low and you are relatively safe. If you
allow passwords, you're open to their attack and if you have any weak
passwords, it's a matter of time.
If you don't allow passwords then your only threat is a brute force
attack using weakly generated keys. There have been a number of
defects and outright attacks on public/private keys over the
years. Most of them have centered on pseudo random number
generation. Break the random number generator or nail down it's
initial state and you limit the number of key-pairs. It is possible to
do this to the point where you can make a dictionary of weak keys. For
a given state that dictionary could be complete. Right now though I
have seen no evidence that the ssh brute force cloud is testing keys
in this manner. I am in fact surprised that the brute force cloud
doesn't enumerate ssh servers that don't accept passwords and leave
them alone. It seems a waste of effort to me to test passwords against
a server that says 'no' to every password. They could continue testing
out of hope that you have a Match clause in sshd_config that allows a
subset of users to login via password or because they have a
dictionary of compromised ssh keys. Maybe they just like annoying the
crap out of sysadmins by filling up their logs.
If you are allowing passwords, and I understand that some places
"must" for various reasons, then the brute force industry may or may
not have a valid username/password pair for your server in their
dictionary. If they do, SSHguard will not stop them from finding
it. It will probably delay them from finding it and it may delay them
for months or years but it is only a delay. SSHguard triggers against
invalid credentials detection in your log files. By definition, valid
credentials don't generate the log entry that SSHguard needs to take
action. The action that SSHguard takes it so block access to the
offending IP address of a server that tries bad credentials too
often. It would be naive to think that brute force mechanism can't
detect when it's black-holed and try a different host.
If you can't mitigate your risk by requiring keys you should require
high complexity passwords and periodically use a password audit tool
against your credentials database to insure that those rules are being
followed.
No matter what you do, you should employ defense in depth. By
extending the amount of time it takes to crack your defenses SSHguard
can be a part of that. It can also put your firewall back into your
overall defense strategy. But at the end of the day, if you're using
SSHguard as your single line of defense, you are really just hoping
that a group of people who have shown amazing patience are just going
to give up on attacking your defenses and move on to your neighbors
because your castle is taking too long to get into.=20
There's lots of good resources on this subject. Michael Lucas' book:
"SSH Mastery" is a short read and has great advice on hardening your
ssh server while allowing you to continue functioning in a more secure
environment. Peter Hansteen has written and talked extensively about
the brute force cloud in his blog. An early article in the series is
here:
http://bsdly.blogspot.ca/2008/12/low-intensity-distributed-bruteforce.=
html
I really think that consulting one or both of these sources can go a
long way towards taking informed action on this problem.
--=20
Chris
__o "All I was trying to do was get home from work."
_`\<,_ -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton [chris/at/vindaloo/dot/com]
--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWDWQfAAoJEE2ar4QHIpj4/swP/2J/LuCq0VgGQ4UeCmtS2Rrm
5Kr9DjW6ik68ZsS8W98/qd4BE1zwh8jbvAXcSkKFK5h1hlQhLdlQYv1IhIY9s7Gj
dCdi61Tsy+8QNWHiR4chL6F3d1jPb/whwaJa+sYn/9q5OyGKqJpv4nhE+2UZVY73
GmuLlIJxLm08n/pe1zx6g2paHUJiZaqZkDq7j/pDU4Iv1GdQXNO0TW9J+egz8Orh
6cdCaqRfmbE2MVuvMxmjO/eqDzOTYmZhNrrWpJFasoVKG0hqax3+rPCzh/vtB5bb
cj9dPvzKbVqpfRw3Ng3Uu60IbgABOk/rFVfixCrAbmOR0o+PtJZje6wSe7KFUqgm
5yISqPPwN0RXALfO+95yRdWiZ/yngbBKaYQVPoMC1K8tLU36zap7t6tmS6iroXIT
RtjukiX3Xs+F3hUHZSCv27uD65zwcXON4K4waxDWI4UZsciVHxgSogRaP6XrRkeg
mI7v4bq3/hEP80MlaBbtbodpn3nXWrXZOnfvX7/Qck6MTV3HwyixoNFlhI5SdoxK
K+zFt1IcsyJOmoFgyg7tZIdV5PO1xRSYZNObx1fXKC6mQTfZtf0dkJXfaGt9pAJi
1HHuZG9rkk/EgEYBPo2fPM6MX9BT3lKtor0Q+jMouiGti8HwPiZpXn+4JwmBRS4x
THcQDu2O3e3PBdPjK2hs
=Giro
-----END PGP SIGNATURE-----
--LZvS9be/3tNcYl/X--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151001164935.GA1268>