From owner-freebsd-questions@freebsd.org Thu Oct 1 16:57:48 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 144AEA0D935 for ; Thu, 1 Oct 2015 16:57:48 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from yavin.vindaloo.com (yavin.vindaloo.com [72.52.97.79]) by mx1.freebsd.org (Postfix) with ESMTP id EB4FD1E84 for ; Thu, 1 Oct 2015 16:57:47 +0000 (UTC) (envelope-from chris@vindaloo.com) Received: from anza.vindaloo.com (ool-457cdf63.dyn.optonline.net [69.124.223.99]) by yavin.vindaloo.com (Postfix) with ESMTP id 8A8C25082C for ; Thu, 1 Oct 2015 12:50:55 -0400 (EDT) Received: from hadar.local (hadar.vindaloo.com [172.24.145.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anza.vindaloo.com (Postfix) with ESMTPSA id 1761B101CD for ; Thu, 1 Oct 2015 12:50:55 -0400 (EDT) Resent-From: Christopher Sean Hilton Resent-Date: Thu, 1 Oct 2015 12:50:54 -0400 Resent-Message-ID: <20151001165054.GB1268@hadar.local> Resent-To: User Questions X-Original-To: chris@vindaloo.com Delivered-To: chris@vindaloo.com Received: from hadar.local (hadar.vindaloo.com [172.24.145.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anza.vindaloo.com (Postfix) with ESMTPSA id D378D101CD; Thu, 1 Oct 2015 12:49:40 -0400 (EDT) Date: Thu, 1 Oct 2015 12:49:35 -0400 From: Christopher Sean Hilton To: Ian Smith Subject: Protecting sshd - Was: SSHguard & IPFW Message-ID: <20151001164935.GA1268@hadar.local> References: <20151001033001.R67283@sola.nimnet.asn.au> <20151001173313.T67283@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20151001173313.T67283@sola.nimnet.asn.au> User-Agent: Mutt/1.5.23 (2014-03-12) X-Loop: mail.vindaloo.com X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 16:57:48 -0000 --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--