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:
I've looked around and found several linux-centric things designed to
block brute-force SSH attempts. Anyone out there know of something
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
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
of direct or random attacks by a lot, then deal with attacks using
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
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
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
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"