Everyone: We're starting to see a rash of password guessing attacks via SSH on all of our exposed BSD servers which are running an SSH daemon. They're coming from multiple addresses, which makes us suspect that they're being carried out by a network of "bots" rather than a single attacker. But wait... there's more. The interesting thing about these attacks is that the user IDs for which passwords are being guessed aren't coming from a completely fixed list. Besides guessing at the passwords for root, toor, news, admin, test, guest, webmaster, sshd, and mysql, the bots are also trying to get into our mail exchangers via user IDs which are the actual names of users for whom the machines receive mail. In one case, we saw an attempt to use the name of a user who hadn't been on for years but whose address was published ONCE (according to Google and AltaVista) on the Net. Since the attackers are not guessing at hundreds of invalid user names, the only conclusion we can draw is that when one of the bots attacks a mail server, it quickly tries to harvest e-mail addresses from the server's domain from the Net and then tries them, in the hope that those users (a) are enabled for SSH and (b) have weak passwords. SSH is enabled by default in most BSD-ish operating systems, and this makes us a bigger target for these bots than users of OSes that don't come with SSH (not that they're not more vulnerable in other ways!). Therefore, it's strongly recommended that, where practical, everyone limit SSH logins to the minimum possible number of users via the "AllowUsers" directive. We also have a log monitor that watches the logs (/var/log/auth.log in particular) and blackholes hosts that seem to be trying to break in via SSH. --Brett Glass
On 2 Oct, Brett Glass wrote:> Everyone: > > We're starting to see a rash of password guessing attacks via SSH > on all of our exposed BSD servers which are running an SSH daemon. > They're coming from multiple addresses, which makes us suspect that > they're being carried out by a network of "bots" rather than a single attacker. > > But wait... there's more. The interesting thing about these attacks > is that the user IDs for which passwords are being guessed aren't > coming from a completely fixed list. Besides guessing at the > passwords for root, toor, news, admin, test, guest, webmaster, > sshd, and mysql, the bots are also trying to get into our mail > exchangers via user IDs which are the actual names of users for > whom the machines receive mail. In one case, we saw an attempt to > use the name of a user who hadn't been on for years but whose > address was published ONCE (according to Google and AltaVista) on > the Net. Since the attackers are not guessing at hundreds of > invalid user names, the only conclusion we can draw is that when > one of the bots attacks a mail server, it quickly tries to harvest > e-mail addresses from the server's domain from the Net and then > tries them, in the hope that those users (a) are enabled for SSH > and (b) have weak passwords. > > SSH is enabled by default in most BSD-ish operating systems, and > this makes us a bigger target for these bots than users of OSes > that don't come with SSH (not that they're not more vulnerable in > other ways!). Therefore, it's strongly recommended that, where > practical, everyone limit SSH logins to the minimum possible number > of users via the "AllowUsers" directive. We also have a log monitor > that watches the logs (/var/log/auth.log in particular) and > blackholes hosts that seem to be trying to break in via SSH.It's also a good idea to only allow public key authentication from remote hosts. This avoids the risks of password guessing and password capture by shoulder surfers or key loggers.
At 04:12 PM 10/2/2005, Daniel Gerzo wrote:>very nice is to use AllowUsers in form of user@host.If you can get away with it, absolutely. Same with the RSA keys. Of course, the problem is that if you need to get access in an emergency from who-knows-where, you're pretty much stuck with passwords unless you have a token system or a one time password system (e.g. S/Key). (Which reminds me: Anyone have a good S/Key implementation for the Palm Pilot?)>> We also have a log monitor >> that watches the logs (/var/log/auth.log in particular) and >> blackholes hosts that seem to be trying to break in via SSH. > >I wrote a similar script. it's also in ports under >security/bruteforceblockerThe system we're using is the general purpose log monitor I described at BSDCon in San Francisco. It's written in SNOBOL4 and has nice features like amnesty and rate limiting. --Brett
On Sun, 02 Oct 2005 16:01:26 -0600 Brett Glass <brett@lariat.org> wrote: : Everyone: : : We're starting to see a rash of password guessing attacks via SSH : on all of our exposed BSD servers which are running an SSH daemon. : They're coming from multiple addresses, which makes us suspect that : they're being carried out by a network of "bots" rather than a single attacker. : : But wait... there's more. The interesting thing about these attacks : is that the user IDs for which passwords are being guessed aren't : coming from a completely fixed list. Besides guessing at the : passwords for root, toor, news, admin, test, guest, webmaster, : sshd, and mysql, the bots are also trying to get into our mail : exchangers via user IDs which are the actual names of users for : whom the machines receive mail. In one case, we saw an attempt to : use the name of a user who hadn't been on for years but whose : address was published ONCE (according to Google and AltaVista) on : the Net. Since the attackers are not guessing at hundreds of : invalid user names, the only conclusion we can draw is that when : one of the bots attacks a mail server, it quickly tries to harvest : e-mail addresses from the server's domain from the Net and then : tries them, in the hope that those users (a) are enabled for SSH : and (b) have weak passwords. : : SSH is enabled by default in most BSD-ish operating systems, and : this makes us a bigger target for these bots than users of OSes : that don't come with SSH (not that they're not more vulnerable in : other ways!). Therefore, it's strongly recommended that, where : practical, everyone limit SSH logins to the minimum possible number : of users via the "AllowUsers" directive. We also have a log monitor : that watches the logs (/var/log/auth.log in particular) and : blackholes hosts that seem to be trying to break in via SSH. : Great email Brett, this is ineed a true revelation we all at freebsd-security@ have been waiting for. B.T.W, did you also notice they harvest email addresses and send you useless information about products you don't need? I shit you not. One needs to be carefull since SMTP servers are avaliable by default in most BSD-ish operating systems, and this makes us a bigger target for these email bots than users of OSes that don't come with SMTP (not that they're not more vulnerable in other ways!). Cheers, Marcin.
On Oct 2, 2005, at 5:01 PM, Brett Glass wrote:> Everyone: > > We're starting to see a rash of password guessing attacks via SSH > on all of our exposed BSD servers which are running an SSH daemon. > They're coming from multiple addresses, which makes us suspect that > they're being carried out by a network of "bots" rather than a > single attacker. > > But wait... there's more. The interesting thing about these attacks > is that the user IDs for which passwords are being guessed aren't > coming from a completely fixed list. Besides guessing at the > passwords for root, toor, news, admin, test, guest, webmaster, > sshd, and mysql, the bots are also trying to get into our mail > exchangers via user IDs which are the actual names of users for > whom the machines receive mail. In one case, we saw an attempt to > use the name of a user who hadn't been on for years but whose > address was published ONCE (according to Google and AltaVista) on > the Net. Since the attackers are not guessing at hundreds of > invalid user names, the only conclusion we can draw is that when > one of the bots attacks a mail server, it quickly tries to harvest > e-mail addresses from the server's domain from the Net and then > tries them, in the hope that those users (a) are enabled for SSH > and (b) have weak passwords. > > SSH is enabled by default in most BSD-ish operating systems, and > this makes us a bigger target for these bots than users of OSes > that don't come with SSH (not that they're not more vulnerable in > other ways!). Therefore, it's strongly recommended that, where > practical, everyone limit SSH logins to the minimum possible number > of users via the "AllowUsers" directive. We also have a log monitor > that watches the logs (/var/log/auth.log in particular) and > blackholes hosts that seem to be trying to break in via SSH. > > --Brett GlassThis is pretty common, I'm afraid. SSH scanning with brute force password guessing has gone through the roof in the last 9-12 months, but it's been going on for years. We announce a /19 worth of space, and see several hundred ssh connects per second across it. The amount of junk port 22 traffic has exceeded the amount of junk port 25 traffic for us now. The best practice I can advise you with: Block port 22 traffic at your ingress for hosts that don't need to accept ssh connections. Turn off SSH on boxes that don't need it at all. If you only ever need to connect from a small list of hosts, block port 22 from anything but those.
yep [root@snoopy ~]#grep Root /etc/ssh/sshd_config PermitRootLogin no mario;> So, Jared Hall wrote:> Is there a way to block root login over 22? > Jared > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org"
On Sun, 2 Oct 2005, Brett Glass wrote:> But wait... there's more. The interesting thing about these attacks is > that the user IDs for which passwords are being guessed aren't coming > from a completely fixed list. Besides guessing at the passwords for > root, toor, news, admin, test, guest, webmaster, sshd, and mysql, the > bots are also trying to get into our mail exchangers via user IDs which > are the actual names of users for whom the machines receive mail.I had a similar fear myself, but when I took a closer look, I realised it was not actually the case that the attackers had specific knowledge of the users on my server. What happens is that there are two kinds of messages from ssh in /var/log/auth.log. When an attacker tries a nonexistent user, you get Oct 2 13:00:03 plexi sshd[79194]: Illegal user bob from 83.142.49.11 When an attacker tries an existing user, you get Oct 2 13:01:47 plexi sshd[79286]: Failed password for www from 83.142.49.11 port 42480 ssh2 In my case, attackers are trying a big list of usernames, and I get both kinds of messages in my auth.log. However, in the daily security mail to root, only the "Failed password" messages are included, so if that's all you see you get the impression that attackers are specifically targetting your users. At least, that is what I thought at first. But when I took a closer look at auth.log, it became clear that that's not what was really happening. Maybe this is the case for Brett as well. -- Tod McQuillin
Tod McQuillin wrote:> What happens is that there are two kinds of messages from ssh in > /var/log/auth.log. When an attacker tries a nonexistent user, you get > > Oct 2 13:00:03 plexi sshd[79194]: Illegal user bob from 83.142.49.11 > > When an attacker tries an existing user, you get > > Oct 2 13:01:47 plexi sshd[79286]: Failed password for www from > 83.142.49.11 port 42480 ssh2I happen to see different entries in my daily security run output: Failed password for illegal user qscand from 217.20.119.212 port 50657 ssh2 So I guess I am noticed about both kinds of attacks. By the way, does anyone of you see a threat in disclosing this kind of log output to the network abuse departments of the corresponding hosters? Often, I encounter intrusion attempts from rented servers where there is an authority above the abuser able to step in. And --on an unrelated matter-- funny to see that we even have trolls here. :) Cheers Clemens
Hello Brett, Monday, October 3, 2005, 12:01:26 AM, you wrote:> Everyone:> We're starting to see a rash of password guessing attacks via SSH > on all of our exposed BSD servers which are running an SSH daemon. > They're coming from multiple addresses, which makes us suspect that > they're being carried out by a network of "bots" rather than a single attacker.> But wait... there's more. The interesting thing about these attacks > is that the user IDs for which passwords are being guessed aren't > coming from a completely fixed list. Besides guessing at the > passwords for root, toor, news, admin, test, guest, webmaster, > sshd, and mysql, the bots are also trying to get into our mail > exchangers via user IDs which are the actual names of users for > whom the machines receive mail. In one case, we saw an attempt to > use the name of a user who hadn't been on for years but whose > address was published ONCE (according to Google and AltaVista) on > the Net. Since the attackers are not guessing at hundreds of > invalid user names, the only conclusion we can draw is that when > one of the bots attacks a mail server, it quickly tries to harvest > e-mail addresses from the server's domain from the Net and then > tries them, in the hope that those users (a) are enabled for SSH > and (b) have weak passwords.> SSH is enabled by default in most BSD-ish operating systems, and > this makes us a bigger target for these bots than users of OSes > that don't come with SSH (not that they're not more vulnerable in > other ways!). Therefore, it's strongly recommended that, where > practical, everyone limit SSH logins to the minimum possible number > of users via the "AllowUsers" directive.very nice is to use AllowUsers in form of user@host.> We also have a log monitor > that watches the logs (/var/log/auth.log in particular) and > blackholes hosts that seem to be trying to break in via SSH.I wrote a similar script. it's also in ports under security/bruteforceblocker> --Brett Glass-- Sincerely, Daniel Gerzo
> PermitRootLogin noi like PermitRootLogin without-password randy
On 10/3/05, mario <mario@schmut.com> wrote:> So, Jared Hall wrote: > > Is there a way to block root login over 22? > > Jared > > ______________________ > > yep > > [root@snoopy ~]#grep Root /etc/ssh/sshd_config > PermitRootLogin noThis is not sufficient if ssh is using PAM for authentication (because PAM will allow root logins). Make sure you also have disabled PAM authentication with ChallengeResponseAuthentication no I think both of these settings default to "no" these days, but you might want to check your config to be sure. - Bob
>>>>> "Brett" == Brett Glass <brett@lariat.org> writes:Brett> Everyone: We're starting to see a rash of password guessing Brett> attacks via SSH on all of our exposed BSD servers which are Brett> running an SSH daemon. They're coming from multiple addresses, Brett> which makes us suspect that they're being carried out by a Brett> network of "bots" rather than a single attacker. [...] Brett> SSH is enabled by default in most BSD-ish operating systems, Brett> and this makes us a bigger target for these bots than users of Brett> OSes that don't come with SSH (not that they're not more Brett> vulnerable in other ways!). Therefore, it's strongly Brett> recommended that, where practical, everyone limit SSH logins to Brett> the minimum possible number of users via the "AllowUsers" Brett> directive. We also have a log monitor that watches the logs Brett> (/var/log/auth.log in particular) and blackholes hosts that Brett> seem to be trying to break in via SSH. I have another angle. I run the following script on many of my machines: #!/bin/bash # Copyright (c) 2005 DaveG.ca # You may use this code under the GPL, version 2 or newer. # firewall excessive ssh attempts PATH=/bin:/sbin:/usr/bin:/usr/sbin cat /var/log/auth.log | grep "Illegal user" | rev | cut -d\ -f 1 | rev | sort | uniq -c | \ ( while read num ip; do if [ $num -gt 9 ]; then if ! ipfw show | grep -q $ip ; then echo adding $ip for $num violations logger -p auth.warn blocking $ip for $num violations ipfw table 1 add $ip fi fi done ) Now... the line 'ipfw ...' can be replace with other firewall statements or it can be a route add -blackhole. The trick here is that it is unusual for legal users to make many tries at an ssh with a completely wrong username. Dave. -- ===========================================================================|David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================