On 2006 Sep 19 , at 17:25, Nicolas Blais wrote:

On Tuesday 19 September 2006 17:12, Joao Barros wrote:
On 9/19/06, Dan Mahoney, System Admin <[EMAIL PROTECTED]> wrote:
Hey all,

I've looked around and found several linux-centric things designed to
block brute-force SSH attempts. Anyone out there know of something a bit
more BSD savvy?

My best attempt will be to get this:


running and adapt it.

I've found a few things based on openBSD's pf, but that doesn't seem to
be the default in BSD either.

Any response appreciated.

I'm using BruteForceBlocker quite successfully.
I take the opportunity to thank danger for it :-)


This has been a recent annoyance for me too, so I did a bit of research. At my site I run a number of Solaris, FreeBSD, NetBSD, and OpenBSD based machines (very few Linux machines.) So I googled for a very BSD specific solution to the problem. The issue of actual cracking doesn't concern me. (All user passwords are strong, and users have strong limitations.) What bothers me is that there's several hundred kilobytes worth of "invalid user" entries in my /var/log/auth.log. It's been rotated about 30 times these past 2 weeks. I preserve ALL logs (/etc/newsyslog.conf has 500 count for each log.) There is also the DoS potential that worries me.

The solutions I read were for OpenBSD pf (which is my router) but could be used on FreeBSD pf, too. It seems that most of these bruteforce ssh attempts come from compromised Linux boxes. As a simple solution, one could add a pf rule which just drops linux hosts on port 22. As a stopgap measure for valid users, who login from linux boxes, I leave open port 2222, and inform these users to use that port.

In addition to all of this, I also run bruteforceblocker, and maintain my own list of denied hosts. (Any host with more than 5 entries for all different invalid users is permanently banned.)

I like to protect myself by hiding what I have, which will reduce the amount of direct or random attacks by a lot, then deal with attacks using tools
(like bruteforceblocker).

Hiding your services is always a good idea. But it also potentially invites portscans, or other evils.

This is especially useful when attackers are using ip-range tools to scan
common ports for their associated service.

Eventually when we all do that, the attackers will just develop (or in most cases, one will, and the others will "borrow") new tools to harass us more.

Why keep sshd on port 22?

Why not keep it there? Why should we all resort to migrating our standard services to non-standard ports, simply because a few [expletives deleted] script kiddies can't keep their packets to themselves? It's also advocating security by obscurity, to hide sshd on another port. Eventually the "bad guys" will just test every port, and we'll have more unnecessary traffic to the box.

I don't know about you, but I'm not going to let a few immature teenagers who've hijacked a network of Linux boxes, setup by a "know-it-all" Linux newbie for his folks, bully me out of doing things the right way, or hiding outside of standardized channels. Certainly never invite trouble... But running from it doesn't make you much safer. (Maybe it's time somebody whipped up a rule for pf, that would direct garbage replies in response to packets we want to deny, instead of just dropping them? Actually, it probably won't do much to the attackers, besides confuse them.)


Adam David Alan Martin

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to