NetBSD-3.1 was attacked: Bug of SSHD or cyrus-sasl?

[Pavel Cahyna]

Question 5) empty password means needn't password?
Or means any passwords are invalid?

needn't password. see the passwd(5) manual page.

btw on my system, when I've installed cyrus-sasl, the cyrus user has the
password disabled (it is all asterisks).

But for some reason it has /bin/sh as shell, not /sbin/nologin.

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Sheryn]

Date: Fri, 12 Jan 2007 22:20:12 +1100 (EST)
Subject: Re: NetBSD-3.1 was attacked: Bug of SSHD or cyrus-sasl?
I've had someone do something similar on not only my NetBSD on Alpha, but also
Debian running on m68k. Although from what I could tell the guy couldn't get
in but same kind of thing, always tries stupid names like mgrt1 or something,
and just common first names, as well as account names like root and admin. All
night. It was coming from some place that had an empty website (that is, it
was running a web server). Can't remember where from now. He also tried to
break a friend's linux i386 box in much the same fasion. I'm kind of eager to
find out how he managed to break the cyrus account. I suppose the best
temporary solution is to change all non-user accounts to use nologin? Is there
a way of implementing a block on any IP addresses that try to login too much?
That would probably slow down the crackers ability to brute force a login, or
whatever it is that he does.

http://fail2ban.sourceforge.net/ or similar ? (not tried it myself) Any
other suggestions ?

[Hubert Feyrer]

Post by David Sheryn
http://fail2ban.sourceforge.net/ or similar ? (not tried it myself) Any
other suggestions ?

See "Fighting ssh password guessing attempts (Update #2)" at
http://www.feyrer.de/NetBSD/blog.html/nb_20060107_2016.html


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rhialto]

Post by Hubert Feyrer

Post by David Sheryn
http://fail2ban.sourceforge.net/ or similar ? (not tried it myself) Any
other suggestions ?

See "Fighting ssh password guessing attempts (Update #2)" at
http://www.feyrer.de/NetBSD/blog.html/nb_20060107_2016.html

I wonder if this kind of thing can't be done with a PAM module? It would
be much more efficient than tail-ing a logfile.

I am running a slightly changed version of the above script: I also look
for the pattern "Illegal user .* from" to block and my "block in" filter
rules are in "group 200" which others might not have.

#!/bin/sh

# Block unauthorised login attempts using only system tools
# Inspired by Hubert Freyer's 'challenge' to write a script that just used
# tail to do the work
# (c) Ian Spray and Hubert Fyerer, 2006

# Use it for what you will: no restrictions, and no warranty

TAIL=/usr/bin/tail
SED=/usr/bin/sed
IPF=/sbin/ipf
CMD_PERM='/usr/bin/tee -a /etc/ipf.conf | '
LOG_FILE='/var/log/authlog'

# uncomment the following line if you want bans to be temporary
# CMD_PERM=''

${TAIL} -F ${LOG_FILE} | while read LOG_LINE
do
echo "${LOG_LINE}" \
| ${SED} -n \
-e '/127\.0\.0\.1/d' \
-e '/192\.168\.0\./d' \
-e '/10\.0\./d' \
-e 's/.*Failed password .* from \([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\).*/block in log quick from \1.\2.\3.\4 to any group 200/p' \
-e 's/.*Illegal user .* from \([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\)\.\([0-9]\{1,3\}\).*/block in log quick from \1.\2.\3.\4 to any group 200/p' \
| /usr/bin/tee -a /etc/ipf.conf | ${IPF} -A -f -
# | ${CMD_PERM} ${IPF} -A -f -
done

-Olaf.

[OBATA Akio]

Post by David Sheryn
http://fail2ban.sourceforge.net/ or similar ? (not tried it myself) Any
other suggestions ?

How about using pkgsrc/security/pam-af ?

--
"Of course I love NetBSD":-)
OBATA Akio / ***@NetBSD.org


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

In the recent days, a cracker always attack my host.
The cracker's IP is from Japan, Croatia and some coutries.
But I guess it is the same cracker and remote-conrolled those hosts.
1) try to ssh account one by one: root, postfix, ... cyrus.
2) at last, login successfully via account cyrus.
3) install a program psyBNC 2.3.1 under /tmp and run it.
4) sometimes he changes the password of cyrus.
Question 1) Is it a bug of sshd?

Probably not. I'm one of the ones who likes to believe that any bugs
in ssh will be quickly known and public. Maybe that's too optimistic.

Question 2) why /etc/passwd:cyrus has Shell: /bin/sh?
I think /sbin/nologin is enough.
In fact, when I change it to /sbin/nologin, the cracker stop cracking
because he has to logout once he login.

Seems like a good idea to mee.

I had the ssh phishers too, and this is a good way to keep them away
from you and working on someone else:

1. Change your ssh port to something else
2. Set pf to block with a drop policy, so the scanners and hackers
have to wait if they do try (which means they will likely go play
somewhere else in short order).
3. Figure out a way to log attempts to connect to port 22 and then
block those IPs (it's on my list of things to do, I just haven't
figured out how I'm going to do it yet. I think someone else posted a
link)

I'm surprised that a few people think you should start over. I would
seriously hope that a compromised user account wouldn't immediately
prompt paranoia that the box was rooted. I understand that this is a
thoght process that needs to take place, but I would hope that NetBSD
is more hardy than that.

I always keep my install sets somewhere else so I can do a checksum
against some important programs to see if it's been hacked.

I don't claim to be Mr. Security, so you'll probably want to look for
advice from others who have been around a while.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andreas Hallmann]

Hi,
once in this situation I put me compromised machine in an isolated
subnet, firewalled to only allow the functionality it was set up for. If
you are under pressure, this is a way to save time without feeling to
much uncomfortable. But this requires no data of private nature on this
machine.
Hmm cyrus account you said? Ok, think a mail server contains private
data. Moreover it's likely someone used a password there used elsewhere.
I would alert my users and force them to change passwords.

You can secure thinks by putting it into a subnet, no WAN access is
allowed for.
Since this box might be compromised, it should be isolated in a separate
network.
No sniffing can get something useful and any other attempt will bang
against a firewall.
You can set up a mail server, feeding it with LMTP. Moreover this is
your outgoing MTA.


Now you can restrict this network accept incomming LMTP transports and
answer incomming IMAP-requests. You can disallow traffic started from
your imap server. So this machine can't do any harm any more.

But still HE had some time to do something nasty, like fishing for
passwords. And therefore keep an eye on all of your machines.

For your enjoyment: If you like to know him better ... put him in a
chroot-jail and watch him trying.
A shell logging each command can be informative.

cheers AHA

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lubomir Sedlacik]

could this pointless excessive cross-posting stop NOW, please?

thanks.