Date: Sat, 02 Jan 2010 02:19:49 +1100 From: David Rawling <djr@pdconsec.net> To: "freebsd-questions@FreeBSD. ORG" <freebsd-questions@freebsd.org> Subject: Re: Blocking a slow-burning SSH bruteforce Message-ID: <4B3E1295.9050902@pdconsec.net> In-Reply-To: <4B3E0FBD.2010605@sbcglobal.net> References: <4B3E0D11.1080101@pdconsec.net> <4B3E0FBD.2010605@sbcglobal.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/01/2010 2:07 AM, J.D. Bronson wrote: > Few options I can think of in random order...I use #1: > > 1. Run SSH on an obscure port. Seriously, thats one of the easiest > things to do. Since I have done that, I have had ZERO attempts and it > works perfectly as long as users know the odd port. In fact, I dont > know anyone in our IT circle of friends that runs SSH on port 22. > > 2. Consider controlling/limiting access via 'pf' if your running 'pf'. > > Of course with your examples coming from all different IPs, thats not > likely gonna help much. > > 3. Just ignore it - they aren't getting in...similar to spammers being > rejected by RBLs....its traffic, but cant be a whole lot. > > 4. Limit login time window too...I run a very narrow window of time to > login and a LOW number of attempted logins per session. Darn. 1 is out because 22 is the one port that most organisations (including mine) allow out of their networks for administering routers. 2 is unfortunately not an option (as a consultant I do work from many networks) 4 - again I might have to log in any time ... 3 seems the best approach. Thanks for your thoughts, it's good to get second opinions. Dave. -- David Rawling PD Consulting And Security Mob: +61 412 135 513 Email: djr@pdconsec.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B3E1295.9050902>