From owner-freebsd-questions@FreeBSD.ORG Wed Sep 20 09:33:28 2006 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C9816A47E for ; Wed, 20 Sep 2006 09:33:28 +0000 (UTC) (envelope-from norgaard@locolomo.org) Received: from strange.daemonsecurity.com (59.Red-81-33-11.staticIP.rima-tde.net [81.33.11.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB2E43D49 for ; Wed, 20 Sep 2006 09:33:26 +0000 (GMT) (envelope-from norgaard@locolomo.org) Received: from [192.168.7.193] (68.Red-80-34-55.staticIP.rima-tde.net [80.34.55.68]) by strange.daemonsecurity.com (Postfix) with ESMTP id 4AF442E02D; Wed, 20 Sep 2006 11:33:24 +0200 (CEST) Message-ID: <45110ADE.5090005@locolomo.org> Date: Wed, 20 Sep 2006 11:33:18 +0200 From: Erik Norgaard User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Dan Mahoney, System Admin" References: <20060919165400.A4380@prime.gushi.org> <45106397.9080206@locolomo.org> <20060919181232.L68018@prime.gushi.org> In-Reply-To: <20060919181232.L68018@prime.gushi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org Subject: Re: sshd brute force attempts? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 09:33:28 -0000 Dan Mahoney, System Admin wrote: > On Tue, 19 Sep 2006, Erik Norgaard wrote: > >> Along with some good advice. First of all: ssh is not a public service >> like http or smtp where you need anyone to be able to connect. So >> don't let them in the first place. > > It is in this case. It's a web server that allows shell usage (and > encourages it, as I actually advocate the power that comes with a shell > as opposed to the primitive (and less secure) interface you may get with > crap utilities like cpanel, or FTP (where you're at the mercy of the > featureset of your particular app). I think you misunderstood what I meant by public service, or maybe it wasn't clear: By a public service I mean a service available for anyone, even anonymously: You're not going to register the world to let people send mail to your server, (while you may (recommended) require authentication to send mail from your server). Your ssh service should only be available to your users. >> Use a scheme for choosing usernames that avoids common names like >> "james" and avoid publishing usernames on web-sites, e-mail may differ >> from the username. > > This is somewhat unaviodable -- as I allow users to choose them. Well, this is up to you, read the article and you'll see that the user names tried apart from common system names are common English names. You can decide to introduce a policy for new users. It is often desirable to give users an e-mail like firstname.lastname as it makes it easier for other people to remember. >> Disable password based authentication and require ssh-keys if >> possible, best if you can ensure both pasword and key based >> authentication. > > This also assumes that people password their keys, otherwise it actually > *lessens* the security of a thing greatly. Most folks don't. I do wish > there was some standard for forcing applications to not save passwords > (other than OTP). People can always manage access badly. Yes, you may not be sure of password protection on the keys, but the intruder first needs to get a copy of the key. If this is stored on a usb-stick the user carries with him, or only on systems that require local authentication first, then I think you're better off than password based ssh. I think that people can better understand and manage a physical thing like a usb-stick and use that as their key. If the capacity is small enough, it is unlikely that people will use it for other stuff and accidentially delete the key. >> You may still find sshd login denied entries in your log - so what? it >> was denied! This is really only a problem if the traffics saturates >> your connection, or your log files grow so much that you run out of >> diskspace. > > It was denied, yes...but when it's denied for 200 different users from > the same IP, it only takes one user with a weak password (and as much as > I like keys, I personally prefer the passwords). I also find that since > I have a nice web-enabled SSH app (as part of usermin), the key becomes > sorta useless in that case. As you read the article they had a password logger to see what passwords were attempted, quite interesting very very weak passwords. You can easily weed out bad password by running a cracker and forcing your users to change. I would like to find an alternative to passwd that can enforce a password policy, like min. 8 chars, upper AND lower case chars and numbers. >> The article also comments on moving ssh to a different port, but this >> causes confusion and annoyance if you have many users and is >> non-standard. Doing the other things works great, an ssh-key on a >> usb-keyring is great. > > For anyone savvy, yes. I don't assume that level of savvy. Well, then - can't you also assume that people can use keys and understand that these should be protected by passwords? >> Personally, I created a script for parsing the delegated files from >> the different regional registries such as only to allow connection >> from EU countries. > > Sounds interesting, is it public? http://www.daemonsecurity.com/pub/src/tools/cc-cidr.pl The output is just a list of cidr addresses that can be used in tables with packet filter. Or edit to create the output you want. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9