Re: [tor-talk] Blocking Shadowserver honeypots
On 19/03/2011 00:02, Alexander Bernauer wrote: > I don't quite understand how any attacker is trapped by a honepot > that is publicly marked as being one. Furthermore, I don't know how > this IRC bot is able to operate with mail and web ports only as my > tor exit node is dropping everything else. It is usually windows boxes compromised by mebroot or torpig malware, trying to connect to their botnet control center wia http. Some of the autogenerated CCC domains were precalculated and the domains registered by shadowserver, ISC.org and the like as sinkholes/honeypots. Jan ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Blocking Shadowserver honeypots
> Would it make me a Bad Exit if I would block these hosts with iptables > instead? That would be up to the authority operators, but probably not. If you have contact info set on the relay then we'd ask what's up before setting the BadExit flag. Blocking destinations via iptables is definitely less desirable than doing it via the exit policy since the former doesn't inform Tor clients that you're unwilling to handle the traffic (the connections simply fail). That said, if you both included the current honey pots in your exit policy *and* an iptables rule to cover any future sinkhole IPs I'd highly doubt anyone would mind (just please be sure to have the contact info set in case there's concern). Cheers! -Damian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Blocking Shadowserver honeypots
Hi FYI, I had a short discussion with some guys on the public shadowserver mailing list. Some of them are pretty fanatic indeed and say things like: ---8<--- TOR provides criminals with anonymous access to engage in criminal activity behind a cloak. TOR makes it exponentially more difficult to fight internet abuse. TOR operators are guilty by complicity. TOR is evil. --->8--- and ---8<--- TOR = abuse Running an endpoint should be illegal in itself. --->8--- In contrast, others are quite rational and explained that ---8<--- Our standard policy is to report what we see without any filtering. It is up to the receiving organization to determine what is the correct response. We do not dictate nor require any specific response from our reports. --->8--- I do see their point so I will try to talk to my ISP (once again...) Additionally, I will reject connections to the Shadowserver honeypots to avoid further abuse reports. This does not solve the fundamental conflict between Shadowserver and Tor, but it solves the problem for me and keeps my exit node hopefully up and running. best Alex signature.asc Description: Digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Blocking Shadowserver honeypots
Hi Damian, On Fri, Mar 18, 2011 at 10:06:57PM -0700, Damian Johnson wrote: > Here's what robtex reports for the sinkhole subdomains: Thank you for this list! > so ExitPolicy reject 74.208.15.160, reject 74.208.15.97, reject > 74.208.164.166... etc Would it make me a Bad Exit if I would block these hosts with iptables instead? > PS. We also have a tor-relays list you might find a bit more helpful > for this sort of question: > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays/ Oh, I haven't been aware of this list. Thank you. I will ask for experience in this regard there. best Alex signature.asc Description: Digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Blocking Shadowserver honeypots
Hi Alexander. Thanks for running a relay! > If yes, I wanted to ask if anybody knows a way to check every outgoing TCP > connection for connecting to *.sinkhole.shadowserver.org and dropping it > if needed. I haven't seen any complaints about this with Amunet. The exit policy doesn't accept hostnames (nor wildcards in them) so your best bet is probably to just reject connections to their current honeypots and add more if you keep getting complaints. Here's what robtex reports for the sinkhole subdomains: 74-208-15-160.sinkhole.shadowserver.org 74-208-15-97.sinkhole.shadowserver.org 74-208-164-166.sinkhole.shadowserver.org 74-208-164-167.sinkhole.shadowserver.org 74-208-64-145.sinkhole.shadowserver.org 74-208-64-191.sinkhole.shadowserver.org 87-106-24-200.sinkhole.shadowserver.org 87-106-250-34.sinkhole.shadowserver.org so ExitPolicy reject 74.208.15.160, reject 74.208.15.97, reject 74.208.164.166... etc Cheers! -Damian PS. We also have a tor-relays list you might find a bit more helpful for this sort of question: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
