Re: [tor-relays] Received botnet/drone abuse complaint
> I received a botnet/drone complaint from shadowserver.org today If the complaint was sent directly to you, rather than to you via your ISP, it is unlikely you need to do anything. Unless you're concerned about possibly having your own IP space blacklisted (which is normally an ISP concern). If your ISP is bugging you, there are some abuse templates and general advice docs on the Tor project site that you may find useful. > If I'm reading this correctly, they identify "mebroot" as the source of the That's probably the nasty that was sent, not necessarily the scan and injection platform in use. > My DirPort is set to 80, which may explain that value in the complaint. No, that's more likely to be the 128:80 dest ip/port pair for the flow sourced from your 210:48586 pair. You might find the log format documented at Shadowserver or via google. They obviously didn't bother to include a complete definition of all the fields in the email. > Any thoughts on what to do to avoid further complaints? Shadowserver > addresses the topic of Tor exits here: Try blocking traffic to that IP or some suitable larger subnet of the afflicted IP as might be determined from whois or BGP, for a few months. It's seems to be just a probe, nothing a simple email or config change won't fix. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Received botnet/drone abuse complaint
I received a botnet/drone complaint from shadowserver.org today (delayed due to holidays) regarding my exit node: timestamp ip port type infection cc cc_port 12/29/2011 19:52 173.208.132.210 48586 32097 US MISSOURI KANSAS CITY tcp mebroot ukixxuug.com|MAOS/0EC20201 14DF137A55320641 84.163.151.128 80 3320 DE 1 If I'm reading this correctly, they identify "mebroot" as the source of the problem. As this is a Windows MBR trojan it obviously doesn't apply to my Linux system. I scanned my system anyway and found no unexpected processes running. My DirPort is set to 80, which may explain that value in the complaint. Any thoughts on what to do to avoid further complaints? Shadowserver addresses the topic of Tor exits here: http://www.shadowserver.org/wiki/pmwiki.php/Involve/TORNodesAndReporting Thanks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] planned downtime
> If someone chose to use, or only could use, his relays. > Or to give a reason other than being raided or broke :) A heads up would make sense if he was providing bridges, since that would impact reachability for his users. However, if it's a normal relay then there's really no point in sending a downtime notice. Paul is right that we see hundreds of relays appear or disappear each day and, besides a few particularly huge ones, the downtime probably wouldn't be noticed. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] planned downtime
> Why and for whom is that relevant? Keep in mind that the Tor network > handles churn quite well. If someone chose to use, or only could use, his relays. Or to give a reason other than being raided or broke :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuse complaints about brute forceing via ssh
Am 2012-01-02 12:23, schrieb cmeclax-sazri: > On Sunday 01 January 2012 23:36:13 grarpamp wrote: >> This 'attack' has been going on for YEARS. Nobody's really getting >> shells (well some are), just dictionaried. The problem is that >> OpenSSH logs this by default and people freak out when they >> see it in their logs. It's just background noise. Real admins >> tune it out and use ssh keys instead. > I wrote a shell script that watches the logs and shuts off all access from an > address that starts guessing passwords. That is exactly what tools like "fail2ban" are for. Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] planned downtime
Am 2012-01-02 12:25, schrieb cmeclax-sazri: > Sometime this week (I haven't decided when yet) I'll be down for a few hours > to upgrade memory. > > Why and for whom is that relevant? Keep in mind that the Tor network handles churn quite well. Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] planned downtime
Sometime this week (I haven't decided when yet) I'll be down for a few hours to upgrade memory. cmeclax ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuse complaints about brute forceing via ssh
On Sunday 01 January 2012 23:36:13 grarpamp wrote: > This 'attack' has been going on for YEARS. Nobody's really getting > shells (well some are), just dictionaried. The problem is that > OpenSSH logs this by default and people freak out when they > see it in their logs. It's just background noise. Real admins > tune it out and use ssh keys instead. I wrote a shell script that watches the logs and shuts off all access from an address that starts guessing passwords. My Linux box (which is what you get entering on port 22) doesn't have a root password (I use sudo), so anyone who tries to guess root passwords gets nothing but the door slammed shut in his face. Others try guessing "sales", "pgsql", "tony", "newsletter", "visitor", etc.; I don't think I've ever seen any guess my real username. cmeclax ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
