I'm tired of spew on the consoles and log entries ... and I'd prefer
to shut the door-knob turners out than silence the screaming daemons.
Erik <fa...@netbsd.org>
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
I find moving the service to a different port reduces this
significantly, but I guess it depends on the context you're asking this
question in (ie I understand moving away from port 22 is not necessarily
possible in all circumstances).
-Jan
I have something that I think I got from Luke that he got from Christoph Badura, I think? I don't really know the origin of it.
It's a perl script that camps out on auth.info:
auth.info |exec /usr/local/sbin/ban-ssh-bf -
and parses the sshd failed login attempts. After a few attempts, it adds the hosts' IP to ipfilter's group 22 and logs the banning:
1308706374 211.144.118.60 no identification
1308748742 184.0.209.250 illegal user jbeer
1308753376 24.143.26.76 illegal user jbeer
1308764694 189.109.125.110 failed password for root
1308853847 66.7.155.34 illegal user jbeer
1308916828 220.165.5.7 no identification
1308918105 66.228.37.45 failed password for root
1308949414 98.216.54.244 illegal user jbeer
1308969136 117.120.24.4 no identification
1309033552 61.142.80.59 no identification
1309034245 88.174.84.173 no identification
1309045681 119.161.145.206 no identification
1309049921 123.30.128.15 no identification
1309050716 12.157.117.67 illegal user jbeer
1309051370 216.218.212.69 failed password for root
1309064855 61.130.156.146 failed password for root
1309114909 202.164.212.32 failed password for root
1309121587 219.154.45.50 failed password for root
1309151582 110.74.197.251 illegal user jbeer
I can send you what I have if you like but maybe christoph has a newer version... I think mine is from 2007 sometime.
Turning off PasswordAuthentication works well. It used to be that in
fact you could turn off PasswordAuthentication, then let password
authentication complete via ChallengeResponseAuthentication. I would
expect the bots have gotten smarter about this, but perhaps not.
Thor
Well, personally, I deal with ssh in two ways: (1) by not offering to
accept password authentication at all from arm's-length hosts and (2)
border router blacklisting anyone who exhibits various kinds of
misbehaviour, such as the "Bye Bye" ssh syndrome.
I haven't bothered with anything analogous for FTP. My FTP server
doesn't do non-anonymous logins at all, and the log noise from
doorknob-rattlers is nothing compared to the log spew from googlebot
crawling the whole thing repeatedly.
Mouse
See http://www.feyrer.de/NetBSD/blog.html/nb_20070116_0041.html
- Hubert
> On Mon, Jun 27, 2011 at 04:48:23PM -0400, Jan Schaumann wrote:
>> "Erik E. Fair" <fa...@netbsd.org> wrote:
>>> For those of us with public IP addresses, what is the most popular
>>> and effective way to shut out the various door-knob turners who
>>> keep trying account/password combinations again ssh and other such
>>> services?
>
> Turning off PasswordAuthentication works well.
You have to turn off PAM for sshd as well...
--Steve Bellovin, https://www.cs.columbia.edu/~smb
I'm having fun with PF
table <sshscan> persist
block in quick inet from <sshscan> to any probability 75%
pass in quick inet proto tcp from any to any port ssh keep state
(max-src-conn 10, max-src-conn-rate 3/60, overload <sshscan> flush)
--
Mihai
denyhosts, it's in pkgsrc.
In my case, move my SSH server to a different port. I haven't had
a single dictionary scan since then of which I'm aware. My current
logs go back to Nov. 4th, 2009.
}-- End of excerpt from "Erik E. Fair"
My own personal approach when forced to use popular software without
mods (as OpenSSH often is) is to combine two different software
packages that both perform the same sorts of access-blocking things-
OpenSSH + Daemontools/any-FW-Package/your custom weirdo script
accessing /proc or parsing netstat output etc-
Software exploits are handled at high levels by this approach-
network-level assault isn't helped by that, but that usually means
you've got a dedicated attacker...
The more distant the packages the better, as automated attacks will be
less and less targeted towards them. Assuming you can write principled
code, your own custom checkpoint script backing up a massively-used
commercial package is about as good as it gets...
As an aside- relying upon "random jackoff's" Perl script that performs
some automated port knocking -> FW interaction or Blacklist addition
etc is just asking for misery/mystery- it's one thing when building
some custom scripting around your stack rom your own mind so you are
absolutely intimate with how everything works; it's another when
you're relying on someone else's hack. This isn't meant to knock any
existing examples, but if you can read their code enough to really
well-verify it for your uses, then you could have just written it
yourself, and then there would no ambiguity in your "Do I really
understand what this thing is doing?" equation.
Think Apollo Mission
Aim Space Shuttle
Achieve Freight Train
Your fail-safe continuance measures are now in line with 5 9's of all
of Humanity- congratulations :)
-SS
--
NUNQUAM NON PARATUS
I've found that disabling password authentication completely and using a
pf overload rule is the best solution.
Usually I clear the addresses in the overload table once a week.
As someone else mentioned, moving the service to another port mostly
makes it a moot issue. I don't usually do this because people assume
sshd will be listening on port 22. There's a tradeoff; with the pf rule
I find that the logs don't get that much spammed -- the way I have it
configured, usually after 2 attempts that IP is blocked for a week.
If you can't move the port, and disabling password auths is an option,
the pf overload rule does a good job. Lower MaxAuthTries @ sshd_config too.
However, if disabling passwords isn't a possibility, I guess another
solution would be enforcing strong passwords on NetBSD.
Regards,
Hugo
Indeed. I was about to raise this point too. Plenty of vulnerabilities have
been reported in these tools. Additionally, my personal opinion is that
firewalls should be static, and white lists should be preferred to black
lists. All in all, if you are not dealing with special cases (e.g. company,
university, etc.), these "door-knob turners" are harmless even with just
good passwords.
- Jukka.
> For those of us with public IP addresses, what is the most popular
> and effective way to shut out the various door-knob turners who
> keep trying account/password combinations again ssh and other such
> services?
>
> I'm tired of spew on the consoles and log entries ... and I'd prefer
> to shut the door-knob turners out than silence the screaming daemons.
I use the blockhosts python script:
http://www.aczoom.com/blockhosts/
It hooks into tcpwrappers (via the spawn keyword in /etc/hosts.allow), so
you don't need pf etc, it also dosn't poll log files.
--
[http://pointless.net/] [0x2ECA0975]
> On Mon, 27 Jun 2011, Erik E. Fair wrote:
> > For those of us with public IP addresses, what is the most popular
> > and effective way to shut out the various door-knob turners who
> > keep trying account/password combinations again ssh and other such
> > services?
>
> See http://www.feyrer.de/NetBSD/blog.html/nb_20070116_0041.html
I also wrote a similar SH script:
But I also recommend disabling PAM and password authentication if
possible.
--
Matt
If the bots know how to do ChallengeResponseAuthentication by now,
then yes, you do.