RE: [sec] Re: failed root login attempts
Personaly, I prefere: "AllowGroups ssh" so that i have to give a user explicit ssh access by adding him/her to the ssh group. Offcourse, root is not in this group :p -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: woensdag 29 september 2004 23:48 To: [EMAIL PROTECTED] Cc: Noah Meyerhans Subject: Re: [sec] Re: failed root login attempts * Quoting Phillip Hofmeister ([EMAIL PROTECTED]): > On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > > That doesn't seem to be the case. The most common one uses > > root/test/guest, but there are more that seem to be based on the same > > code. They all disconnect by sending the string "Bye Bye", e.g.: > > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > > > I've seen many more aggressive root login attempts, as well as 'admin' > > and a number of other users. > > > > The somewhat unsetting thing that I'm wondering about is whether these > > machines are all sharing some big central password dictionary and are > > logging their attempted passwords to some central database. It ends up > > being some massive distributed dictionary attack, which I doubt is going > > to work on my systems, but I'm 100% sure that there are systems out > > there with weak root passwords. > > Best practices suggest: > > PermitRootLogin no Why not: PasswordAuthentication no UsePAM no - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
* Quoting Phillip Hofmeister ([EMAIL PROTECTED]): > On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > > That doesn't seem to be the case. The most common one uses > > root/test/guest, but there are more that seem to be based on the same > > code. They all disconnect by sending the string "Bye Bye", e.g.: > > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > > > I've seen many more aggressive root login attempts, as well as 'admin' > > and a number of other users. > > > > The somewhat unsetting thing that I'm wondering about is whether these > > machines are all sharing some big central password dictionary and are > > logging their attempted passwords to some central database. It ends up > > being some massive distributed dictionary attack, which I doubt is going > > to work on my systems, but I'm 100% sure that there are systems out > > there with weak root passwords. > > Best practices suggest: > > PermitRootLogin no Why not: PasswordAuthentication no UsePAM no - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
On Tue, 28 Sep 2004 at 09:18:51PM -0400, Noah Meyerhans wrote: > That doesn't seem to be the case. The most common one uses > root/test/guest, but there are more that seem to be based on the same > code. They all disconnect by sending the string "Bye Bye", e.g.: > sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye > > I've seen many more aggressive root login attempts, as well as 'admin' > and a number of other users. > > The somewhat unsetting thing that I'm wondering about is whether these > machines are all sharing some big central password dictionary and are > logging their attempted passwords to some central database. It ends up > being some massive distributed dictionary attack, which I doubt is going > to work on my systems, but I'm 100% sure that there are systems out > there with weak root passwords. Best practices suggest: PermitRootLogin no Then again, the people who have weak root passwords are not ones to follow best practices. -- Phillip Hofmeister pgped9HHVcQPF.pgp Description: PGP signature
Re: [sec] Re: failed root login attempts
On Tue, Sep 28, 2004 at 08:23:49PM -0300, Peter Cordes wrote: > Not if the pattern you want to ignore is more than one line. egrep is > purely line-by-line. This worm (or script-kiddie zombie?) always tries > root, admin, then test, ... That doesn't seem to be the case. The most common one uses root/test/guest, but there are more that seem to be based on the same code. They all disconnect by sending the string "Bye Bye", e.g.: sshd[13613]: Received disconnect from 64.246.26.19: 11: Bye Bye I've seen many more aggressive root login attempts, as well as 'admin' and a number of other users. The somewhat unsetting thing that I'm wondering about is whether these machines are all sharing some big central password dictionary and are logging their attempted passwords to some central database. It ends up being some massive distributed dictionary attack, which I doubt is going to work on my systems, but I'm 100% sure that there are systems out there with weak root passwords. > > Has anyone logged the passwords these attacks try? ENOTIME It might set my mind at ease regarding my point above, though. noah pgpufWL8KOAYq.pgp Description: PGP signature
Re: [sec] Re: failed root login attempts
On Tue, Sep 21, 2004 at 01:45:46PM +0100, Steve Kemp wrote: > On Sun, 19 Sep 2004, martin f krafft wrote: > > > > If you ask me, logcheck should learn how to evaluate log messages in > > > their context... > > If you want to have instant alerts of problems then logcheck is > what you want. If you to ignore some things and still receive timely > alerts then you're looking at something which can read your mind! > > If you can define what it is you don't want to see then logcheck > can handle that via the pattern files in logchecks ignore.d/ hierarchy. Not if the pattern you want to ignore is more than one line. egrep is purely line-by-line. This worm (or script-kiddie zombie?) always tries root, admin, then test, ... If it ever starts trying account names that actually exist, and aren't blocked from logging in entirely, I might see if I can get something to use iptables to block that IP for 15minutes after seeing that sequence, since it's a perfect signal that it's a bogus attack, and that it will try a bunch of logins right away, then never come back. Has anyone logged the passwords these attacks try? -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC signature.asc Description: Digital signature
Re: [sec] Re: failed root login attempts
On Sun, 19 Sep 2004, martin f krafft wrote: > > If you ask me, logcheck should learn how to evaluate log messages in > > their context... If you want to have instant alerts of problems then logcheck is what you want. If you to ignore some things and still receive timely alerts then you're looking at something which can read your mind! If you can define what it is you don't want to see then logcheck can handle that via the pattern files in logchecks ignore.d/ hierarchy. It almost sounds like you're wanting to use something different anyway, perhaps logwatch is the package you're looking for? (Not in stable unfortunately, but a backport is trivial). Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: failed root login attempts
On Sun, 19 Sep 2004, martin f krafft wrote: > also sprach Noah Meyerhans <[EMAIL PROTECTED]> [2004.09.19.2219 +0200]: > > As an additional point against these scripts, they are host based. > > If I'm going to bother blackholing the source of these login > > attempts, I'm going to do it at the border. Yes, I can write > > scripts to react to this kind of scanning and have it > > automatically manipulate access lists on the routers, I'm not sure > > I really like the idea. I'm sort of leaning in that direction, at > > this point, though, just to shut up logcheck without telling it to > > ignore all failed root login attempts. > > If you ask me, logcheck should learn how to evaluate log messages in > their context... hmm there are ideas for logcheck after sarge+1, please elaborate. ATM logcheck is a pretty dumb `egrep -v' wrapper of your logs. that symplicity of design has it's strength, but there are for example demands for trigger values. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts [SCANNED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Thurman wrote: | On 9/19/04 1:30 PM, "martin f krafft" wrote: | | |>Other than blacklisting the IPs (which is a race I am going to |>lose), what are people doing? Are there any distinctive marks in the |>SSH login attempt that one could filter on? | | | We are using our hosts.deny files to stop all ssh attempts from ALL IP's and | then add the allowed user IP's in hosts.allow. | | We are also using a script similar to portsentry and logcheck called | logcheckplus which seems to do well, it will immediately lock out the | offending IP and notify you. It works well for dictionary attacks, ftp | kiddies and more. Just change your sshd port and don't worry about it. :/ - -- Ryan Carter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBTt9MidqUDin6C5IRAvwwAJ4qDXiVFlte4cy3ICo7oDaUBjfkVQCeOBp6 b634sp2ObvS/2lUFgyJxFJ8= =WZvf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
* Noah Meyerhans ([EMAIL PROTECTED]) wrote: > As an additional point against these scripts, they are host based. If > I'm going to bother blackholing the source of these login attempts, I'm > going to do it at the border. Yes, I can write scripts to react to this > kind of scanning and have it automatically manipulate access lists on > the routers, I'm not sure I really like the idea. I'm sort of leaning > in that direction, at this point, though, just to shut up logcheck > without telling it to ignore all failed root login attempts. This may or may not be an option for you, but... There's an iptables match called 'ipt_recent' which you can use to blackhole addresses for a period of time. Many of these types of scans will hit an unused address first, or first hit an address/port combination that's not allowed. With ipt_recent you can then blackhole the address for some period of time (say, 60 seconds) which is generally more than long enough for the rest of the scan of your segment to be blocked. Of course, there are potential problems with any kind of automated blacklisting, the main one being the 'DoS' problem. ipt_recent tries to handle this by having the option to also track the TTL which at least makes it a little more difficult to forge packets which will block legitimate hosts. iptables also allows stateful filtering and if you use that then at least outbound connections won't be affected, only inbound ones could be. Stephen signature.asc Description: Digital signature
Re: failed root login attempts [SCANNED]
On 9/19/04 1:30 PM, "martin f krafft" wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), what are people doing? Are there any distinctive marks in the > SSH login attempt that one could filter on? We are using our hosts.deny files to stop all ssh attempts from ALL IP's and then add the allowed user IP's in hosts.allow. We are also using a script similar to portsentry and logcheck called logcheckplus which seems to do well, it will immediately lock out the offending IP and notify you. It works well for dictionary attacks, ftp kiddies and more. -- David Thurman The Web Presence Group http://www.the-presence.com Web Development/E-Commerce/CMS/Hosting/Dedicated Servers 800-399-6441/309-679-0774 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Arthur de Jong <[EMAIL PROTECTED]> [2004.09.20.1201 +0200]: > sshd[21195]: debug1: no match: libssh-0.1 I wonder whether sshd could be somehow made to just ignore when the banner does not match. > I'm not particularly worries since I have PermitRootLogin > without-password in /etc/ssh/sshd_config, only allow a few users > to ssh in anyway (use AllowGroups) and use opie passwords for > logins without a public key. I am more worried that real problems get hidden in between the floods of log entries this crap causes. And you do know that brute force crackers basically give a flying food whether you have opie or normal passwords... the chances differ, but not by much. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 19 Sep 2004, martin f krafft wrote: > Are there any distinctive marks in the SSH login attempt that one could > filter on? The volume in attempts isn't as high here as on your system bug this is what I got when I set loglevel to debug: sshd[21195]: Connection from 211.99.26.89 port 58144 sshd[21195]: debug1: Client protocol version 2.0; client software version libssh-0.1 sshd[21195]: debug1: no match: libssh-0.1 sshd[21195]: Enabling compatibility mode for protocol 2.0 sshd[21195]: debug1: Local version string SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 sshd[21195]: debug1: Starting up PAM with username "root" sshd[21195]: Could not reverse map address 211.99.26.89. sshd[21195]: debug1: PAM setting rhost to "211.99.26.89" sshd[21195]: Failed password for root from 211.99.26.89 port 58144 ssh2 sshd[21195]: debug1: Calling cleanup 0x8052b48(0x0) sshd[21195]: debug1: Calling cleanup 0x806be5c(0x0) (it tries a password immediatly, while normal ssh tries several other things first) A while ago I saw the same thing happen for another account (guest or test I think) but currently only login attempts as root are done I'm not particularly worries since I have PermitRootLogin without-password in /etc/ssh/sshd_config, only allow a few users to ssh in anyway (use AllowGroups) and use opie passwords for logins without a public key. - -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBTqpwVYan35+NCKcRAl2rAJ92UBcG1Ts/bgaHvKzV4wRiGgAOxACgjRXW w/KcIEv31lrIHZqd8wAiqIk= =gV1i -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On Sun, Sep 19, 2004 at 04:16:39PM -0400, Noah Meyerhans wrote: interfere with any random login based password guessing. Especially since, from what I hear about this scanner that's responsible for all these login attempts, it's trying mind-numbingly simple passwords, like root/root, guest/guest, empty passwords, and things like that. There's more than one going around. There's one trying a limited number of simple combinations and there's something else trying to brute force things with a much more extensive algorithm. A suitably paranoid person would wonder if the first thing was just cover for the second. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
martin f krafft <[EMAIL PROTECTED]> writes: > Are there any distinctive marks in the SSH login attempt that one > could filter on? Yes, the SSH banner: my honeyd logs show that of all such attempts, 63% use the banner 'SSH-2.0-windrone2', 35% use the banner 'SSH-2.0-libssh-0.1'. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Noah Meyerhans <[EMAIL PROTECTED]> [2004.09.19.2219 +0200]: > As an additional point against these scripts, they are host based. > If I'm going to bother blackholing the source of these login > attempts, I'm going to do it at the border. Yes, I can write > scripts to react to this kind of scanning and have it > automatically manipulate access lists on the routers, I'm not sure > I really like the idea. I'm sort of leaning in that direction, at > this point, though, just to shut up logcheck without telling it to > ignore all failed root login attempts. If you ask me, logcheck should learn how to evaluate log messages in their context... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 10:09:12PM +0200, martin f krafft wrote: > These scripts already exist. However, they require you to look > continuously. That's not an option. And it has to keep the admin in > the loop (and thus not be an automated blocker) because otherwise > you are open for denial-of-service attacks. As an additional point against these scripts, they are host based. If I'm going to bother blackholing the source of these login attempts, I'm going to do it at the border. Yes, I can write scripts to react to this kind of scanning and have it automatically manipulate access lists on the routers, I'm not sure I really like the idea. I'm sort of leaning in that direction, at this point, though, just to shut up logcheck without telling it to ignore all failed root login attempts. noah pgphAykCqjpee.pgp Description: PGP signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 09:53:23PM +0200, Bernd Eckenfels wrote: > You can either move your ssh to another port, that will greatly reduce the > distributed brute force attacks, or you can put a filter with port knocking > in front of it. Another option is to turn off password authentication, > completely. Neither of these is an option at a large site with dozens or hundreds of ssh users. Maybe if the sysadmins are the only ones who care about ssh it's an option, but where's the fun in that? > > And yes you should be worried about those attacks if you habe weak passwords. That's trivial to fix, even in large sites. Min password lenghts of 8 characters with a minimum of two character classes are going to interfere with any random login based password guessing. Especially since, from what I hear about this scanner that's responsible for all these login attempts, it's trying mind-numbingly simple passwords, like root/root, guest/guest, empty passwords, and things like that. noah pgpQFIu4sdpQp.pgp Description: PGP signature
Re: failed root login attempts
also sprach Bernd Eckenfels <[EMAIL PROTECTED]> [2004.09.19.2153 +0200]: > You can either move your ssh to another port, that will greatly > reduce the distributed brute force attacks, or you can put > a filter with port knocking in front of it. Another option is to > turn off password authentication, completely. All of which are not options when you have a couple hundred users accessing the machine from anywhere on the globe, including from Windoze machines and Internet cafes. > And yes you should be worried about those attacks if you habe weak > passwords. If you have a weak password, you should be worried anyway. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
In article <[EMAIL PROTECTED]> you wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), what are people doing? Are there any distinctive marks in the > SSH login attempt that one could filter on? You can either move your ssh to another port, that will greatly reduce the distributed brute force attacks, or you can put a filter with port knocking in front of it. Another option is to turn off password authentication, completely. And yes you should be worried about those attacks if you habe weak passwords. Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
also sprach Dossy Shiobara <[EMAIL PROTECTED]> [2004.09.19.2203 +0200]: > > If I notice the scan immediately, I will occasionally blackhole > > the source IP at our network border, but it's rare that I notice > > in time. > > That's why I suggested writing something that tail's the syslog > and detects the scan immediately ... These scripts already exist. However, they require you to look continuously. That's not an option. And it has to keep the admin in the loop (and thus not be an automated blocker) because otherwise you are open for denial-of-service attacks. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: failed root login attempts
On 2004.09.19, Noah Meyerhans <[EMAIL PROTECTED]> wrote: > If I notice the scan immediately, I will occasionally blackhole the > source IP at our network border, but it's rare that I notice in time. That's why I suggested writing something that tail's the syslog and detects the scan immediately ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On Sun, Sep 19, 2004 at 02:42:08PM -0400, Dossy Shiobara wrote: > > Other than blacklisting the IPs (which is a race I am going to > > lose), > > Why do you say that? I haven't seen this more than a few times a week > so I haven't bothered to do anything yet, but I'm very close to writing > a script that tail's the syslog and on more than X repeat failures, > add a rule to iptables -j DROP traffic from the offending IP address. I see several of these attempts every day, always hitting sequential IP addresses. When you have dozens of servers that otherwise wouldn't log anything worth a logcheck report, this means lots and lots of unnecessary mail. > If I'm feeling nice, I'll keep a list of the IPs that have been > temporarily blacklisted with a timestamp of when they were added, and > expire them after X time has passed ... I have found it mostly futile to blacklist them at all, unless I catch them as soon as the scanning starts. They hit IP addresses in sequential order, and once they're done scanning my netblock, I haven't seen any more of them. So logcheck, running only once an hour, is useless. It lets me know that such a scan happened, but by the time I get the mail, I don't care. If I notice the scan immediately, I will occasionally blackhole the source IP at our network border, but it's rare that I notice in time. noah pgpQVMcxhr9qu.pgp Description: PGP signature
Re: failed root login attempts
On Sun, 19 Sep 2004, Dossy Shiobara wrote: > On 2004.09.19, martin f krafft <[EMAIL PROTECTED]> wrote: > > Other than blacklisting the IPs (which is a race I am going to > > lose), > Why do you say that? I haven't seen this more than a few times a week > so I haven't bothered to do anything yet, but I'm very close to writing > a script that tail's the syslog and on more than X repeat failures, > add a rule to iptables -j DROP traffic from the offending IP address. > > If I'm feeling nice, I'll keep a list of the IPs that have been > temporarily blacklisted with a timestamp of when they were added, and > expire them after X time has passed ... why don't you create host based access controls? or use only public key authentication? I'm using that for a few years without any problems... ByeZ, WaS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failed root login attempts
On 2004.09.19, martin f krafft <[EMAIL PROTECTED]> wrote: > Other than blacklisting the IPs (which is a race I am going to > lose), Why do you say that? I haven't seen this more than a few times a week so I haven't bothered to do anything yet, but I'm very close to writing a script that tail's the syslog and on more than X repeat failures, add a rule to iptables -j DROP traffic from the offending IP address. If I'm feeling nice, I'll keep a list of the IPs that have been temporarily blacklisted with a timestamp of when they were added, and expire them after X time has passed ... Same goes for failed FTP login attempts ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
failed root login attempts
I am seeing millions (literally) of these in the logs of my machines: sshd[30216]: Failed password for root from 203.71.62.9 port 35778 ssh2 I understand that this is some kind of virus, but it's not making me very happy because logcheck and and some of our IDS systems are going haywire, creating streams of false alarms. Other than blacklisting the IPs (which is a race I am going to lose), what are people doing? Are there any distinctive marks in the SSH login attempt that one could filter on? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: [EMAIL PROTECTED] "i wish there was a knob on the tv to turn up the intelligence. there's a knob called 'brightness', but it doesn't seem to work." -- gallagher signature.asc Description: Digital signature
