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
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]
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 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 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
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
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: Rebuilding packages on *all* architectures
I want to add another point to this discussion. While we cannot prevent malicious maintainers from installing to the archives or poisoning the buildds, requiring all binaries to be remade on the buildds would rule out the possibility that an trojaned maintainer's machine would cause infected software to be distributed in the archives. Security it not absolute. But requiring all architectures to be rebuilt does add a significant amount of security, IMHO. -- 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
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
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
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
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 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]
