- tor-relays - lists.torproject.org

frequency of checking an IP change
by tagnaq 23 Mar '11

23 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm wondering how often Tor tries to detect an IP change of itself and if a relay operator can modify that frequency? Observing the detection point in time and the actual IP change I guess it takes several minutes: - From the logfile: 00:33:30 Tor: Our IP Address has changed from ... to ... The new IP address was actually assigned several minutes before: 00:27:53 (check occurs every 10seconds) It would be valueable to modify the frequency because the relay in question gets a new IP address every few hours (<10h). Looking at the man page I couldn't find anything regarding that frequency. kind regards, tagnaq -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk2J3ZIACgkQyM26BSNOM7b4NwD/QmH0RWDsp0muCy0PFtkE0Gw4 TDNZx4eDYcOLKfvRX5UA/1PdG8w7DYtfvktWGkzBj82d6/gFo68oVJ+QAM8yqvWU =wnE6 -----END PGP SIGNATURE-----

1 0

abuse reports from shadowserver.org
by Alexander Bernauer 20 Mar '11

20 Mar '11

Hi everybody, my ISP keeps on receiving abuse reports from shadowserver.org. They claim that an IRC bot operates from the IP that belongs to my tor exit. The strange thing is that my exit policy only allows web and mail ports. Furthermore, the IPs of the shadowserver honeypots have a ptr entry for *.sinkhole.shadowserver.org. So, I could block their servers either by means of the exit policy or with iptables. Which one would you prefer? I additionally wanted to ask here if there is any experience with shadowserver in this regard? Explaining the issue to my ISP failed. They keep on getting nervous. Talking to shadowserver also failed, because subscription to their public mailing list is moderated and my direct mails have been ignored for several months now. Any advice? regards Alex

6 6

weighting algorithm
by Olaf Selke 15 Mar '11

15 Mar '11

Hi, between Saturday evening and Tuesday afternoon (UTC+1) my relay's bandwidth dropped to about 2/3 of its normal value. Did some changes in directory's weighting algorithm occur during this time period? regards Olaf

5 6

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 10 Mar '11

10 Mar '11

On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris(a)eff.org> wrote: >On Feb 26, 2011, at 9:53 AM, mick wrote: > >> No reputable security researcher would a) scan a network without that >> network owner's explicit permission, nor b) use tor for that scan. > >Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet. Well, as I've just finished describing in another topic here, I treat scanning of my system as attempted security breaches. Such scans will not elicit any apparent response from my system, except that the scanner's IP address will shortly be added to my "block" file, which will deny all future access to my tor node's ORPort and DirPort. > >Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable. > I disagree and, as noted above, treat that as a cracking attempt. tor nodes that you abuse in such fashion will continue to function by the means described below, provided they are listed in the current consensus document. My current procedures are described in the next two paragraphs. However, your implication quoted above that EFF has/does/will abuse tor exits in this manner suggests I may have to modify my treatment of tor exits from which your scans emerge, given the increased likelihood that the offenses did not originate from the exit node's system and that the exit node was instead a victim as well. Nevertheless, your scans will not get responses from my system, except for connection attempts to the ORPort or the DirPort. First, I have set the sysctl variable called net.inet.tcp.blackhole to 2, which causes the kernel to drop all incoming packets addressed to closed ports. The IP addresses of tor nodes, including exit nodes, listed in the cached-consensus file on my system are placed into a "pass" file every 30 minutes, which temporarily exempts them from being checked against the "block" file. It is temporary in that the exemption lasts for 30 minutes only, although it will be exempted for another 30 minutes whenever the address exists in the cached-consensus file at the time the "pass" file is rebuilt. Anyone who may be concerned that their IP address or address range might be listed in my "block" file is welcome to write to me to inquire about it. If it is, then I will offer to remove the block on an indefinitely probationary basis. However, if I encounter the same IP address in my pf log again, then I will block the address permanently. Frankly, I think it's appalling that a previous sponsor organization for the tor project should turn on the tor network in the fashion you've confessed here that it has. I'm tempted to dig out all of the EFF IP address ranges and block them permanently, just as a matter of principle, although it would obviously have little real effect upon your organization. No wonder so many of us have run afoul of our ISPs when trying to run exit nodes when even EFF is trying to spoil the tor network for us. Who needs enemies with "friends" like EFF? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

12 27

first using bridge then become bridge
by Lorenz Kirchner 10 Mar '11

10 Mar '11

Hi everybody, i'm in china and when i start tor nodes (on a linux server) i often have to first start up the node using bridges, after i ran tor for a while i can restart the node as a bridge-no-exit-relay-entry-node, or whatever, and it will (through its cached data, I guess) be able to connect to the tor network.. and, importantly, help other nodes to connect to the tor network. It would be great if the node's mode could automatically change, when I start the tor node it will try to be a bridge relay according to my torrc, if it can not establish a connection it will first use a bridge and when it has enough data (non blocked entry nodes) will return to becoming a relay. Does this make sense? btw i think bridges.torproject.org is blocked in china (perhaps not surprisingly). And also, on linux servers, couldn't the tor node get the bridges via email by itself, that would be fantastic! each tor node could have its own gmail account, but i guess it would probably somehow be a problem for anonymity..? take care :)

4 11

tor not working
by prafull moulekhi 09 Mar '11

09 Mar '11

hi I m having problem in running tor since last 1 week. I am getting the following log. Mar 08 14:17:17.950 [Notice] Initialized libevent version 1.4.14-stable using method win32. Good. Mar 08 14:17:17.950 [Notice] Opening Socks listener on 127.0.0.1:9050 Mar 08 14:17:17.950 [Notice] Opening Control listener on 127.0.0.1:9051 Mar 08 14:17:17.950 [Notice] Parsing GEOIP file. Mar 08 14:17:22.831 [Notice] No current certificate known for authority moria1; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority tor26; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority dizum; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority ides; launching request. Mar 08 14:17:22.831 [Notice] No current certificate known for authority gabelmoo; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority dannenberg; launching request. Mar 08 14:17:22.832 [Notice] No current certificate known for authority urras; launching request.

1 0

about the balls of steel level of relay nodes
by Nicolas Bock 08 Mar '11

08 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, I was running a tor exit node until I came across this article: http://calumog.wordpress.com/2009/03/18/why-you-need-balls-of-steel-to-oper… While I don't live in the UK, I live in the US, I believe that the situation here has eroded to a point where running an exit node requires the mentioned balls of steel, which I admittedly don't have. Since I do want to support the tor project, I am wondering to what extend running a relay node is putting myself and my family at risk of legal prosecution. My understanding is that my host would simply generated encrypted traffic that is not objectionable to the ISP (because they can't look into it) unless the use of tor itself is outlawed. Is that correct? Thanks, nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk11L2cACgkQf15tZKyRylKQKQCgxlmqlOQPy2tUiZW8VsqaiQKv 930AnRW/+5SpltOWtGQr6hwWgJc4RpzG =MoZM -----END PGP SIGNATURE-----

4 3

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 08 Mar '11

08 Mar '11

On Tue, 08 Mar 2011 14:25:16 -0800 Chris Palmer <chris(a)eff.org> wrote: >On 03/08/2011 02:04 AM, Scott Bennett wrote: > >> Frankly, I think it's appalling that a previous sponsor organization for >> the tor project should turn on the tor network in the fashion you've confessed >> here that it has. I'm tempted to dig out all of the EFF IP address ranges >> and block them permanently, just as a matter of principle, although it would >> obviously have little real effect upon your organization. No wonder so many >> of us have run afoul of our ISPs when trying to run exit nodes when even EFF >> is trying to spoil the tor network for us. Who needs enemies with "friends" >> like EFF? > >Do you understand the research we are doing? Do you know technically >what we have done, and what we hope to do, and what the impact has been >and will be? > >If you don't know yet, please check out our page: > >https://www.eff.org/observatory All right, I've looked. I knew someone was doing that sort of thing, but I didn't remember that EFF was involved. It looks interesting and valuable, but quite irrelevant to the point I made. Nothing on that page justifies subjecting tor exit node operators to the abuse and hassle of being shut down by their ISPs because EFF is so crass as to run port scans through the tor network. Nothing on that page justifies damaging the tor network by reducing the exit node pool by getting exit nodes shut down, which also reduces the total number of relays, often for entry and middle usage, too. > >If you have seen and understood that, please explain what about it you >find so objectionable. Note also that the Tor Project is using our Done. See above. >database to improve Tor itself, too. Fine. I don't see that EFF's port scans have to be done through the tor network. > >We are working to make the internet safer for everyone. > Well, sometimes, at least. I'll never forget how John Barlow sold us out during the time of William the Prevaricator, though. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Network Scan through Tor Exit Node (Port 80)
by Bianco Veigel 08 Mar '11

08 Mar '11

Today I got the second abuse mail within two weeks from my hosting provider. They forced me to take down the exit node, otherwise they will shutdown my server. How could I detect such a scan and take counter measures to prevent a network scan through tor? I've thougt about Snort, but I've never used it before. The exit node is running in a Xen-vm, behind a pfSense firewall. I've attached the report from the abuse mail. Does anyone have an idea, what steps should/could be taken? Thanks in advance, Bianco Veigel ----- attachment ----- ########################################################################## # Netscan detected from host 188.40.98.54 # ########################################################################## time protocol src_ip src_port dest_ip dest_port --------------------------------------------------------------------------- Fri Feb 25 06:53:15 2011 TCP 188.40.98.54 45237 => 138.160.29.194 20019 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27681 => 94.207.140.89 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6869 => 94.207.140.93 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 33258 => 94.207.140.94 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 53464 => 94.207.140.95 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 31041 => 94.207.140.96 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6299 => 94.207.140.97 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 40964 => 94.207.140.98 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 8703 => 94.207.140.99 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 56759 => 94.207.140.187 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 26247 => 94.207.140.227 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 26247 => 94.207.140.227 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 27847 => 94.207.140.228 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27847 => 94.207.140.228 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 1219 => 94.207.140.229 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 1219 => 94.207.140.229 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 38929 => 94.207.140.230 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 38929 => 94.207.140.230 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 62958 => 94.207.140.235 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 46469 => 94.207.140.236 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 2704 => 94.207.140.237 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 17272 => 94.207.141.12 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 17272 => 94.207.141.12 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 32482 => 94.207.141.13 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 32482 => 94.207.141.13 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 55860 => 94.207.141.14 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 55860 => 94.207.141.14 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 43390 => 94.207.141.15 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 43390 => 94.207.141.15 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 31712 => 94.207.141.16 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 31712 => 94.207.141.16 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 29316 => 94.207.141.17 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 29316 => 94.207.141.17 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 5286 => 94.207.141.18 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 5286 => 94.207.141.18 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 45139 => 94.207.141.19 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 45139 => 94.207.141.19 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 25311 => 94.207.141.20 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 25311 => 94.207.141.20 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 3675 => 94.207.141.21 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 3675 => 94.207.141.21 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 51753 => 94.207.141.22 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 51753 => 94.207.141.22 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 8993 => 94.207.141.23 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 8993 => 94.207.141.23 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 48305 => 94.207.141.24 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 25717 => 94.207.141.25 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 15142 => 94.207.141.26 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 24618 => 94.207.141.27 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 43060 => 94.207.141.28 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 45003 => 94.207.141.45 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 18691 => 94.207.141.48 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 48452 => 94.207.141.60 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 48452 => 94.207.141.60 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 37237 => 94.207.141.61 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 37237 => 94.207.141.61 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 39153 => 94.207.141.62 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10678 => 94.207.141.63 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 23127 => 94.207.141.64 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10755 => 94.207.141.65 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 13206 => 94.207.141.66 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 32657 => 94.207.141.67 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 1909 => 94.207.141.68 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 3475 => 94.207.141.69 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 3475 => 94.207.141.69 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 1810 => 94.207.141.70 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 1810 => 94.207.141.70 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 52358 => 94.207.141.71 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 3828 => 94.207.141.72 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 46151 => 94.207.141.73 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 17930 => 94.207.141.74 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 4025 => 94.207.141.103 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 4025 => 94.207.141.103 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 48216 => 94.207.141.104 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 48216 => 94.207.141.104 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 61033 => 94.207.141.105 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 61033 => 94.207.141.105 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 35460 => 94.207.141.106 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 35460 => 94.207.141.106 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 34686 => 94.207.141.107 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 34686 => 94.207.141.107 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 8517 => 94.207.141.108 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 8517 => 94.207.141.108 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 34989 => 94.207.141.109 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 16795 => 94.207.141.110 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 54679 => 94.207.141.111 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 36103 => 94.207.141.112 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 59119 => 94.207.141.113 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 29831 => 94.207.141.114 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 24490 => 94.207.141.115 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 8880 => 94.207.141.116 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 43624 => 94.207.141.117 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 31266 => 94.207.141.118 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 33438 => 94.207.141.119 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 43359 => 94.207.141.120 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 8168 => 94.207.141.121 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 36716 => 94.207.141.122 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 5648 => 94.207.141.123 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 57277 => 94.207.141.124 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 20586 => 94.207.141.134 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 20586 => 94.207.141.134 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 29953 => 94.207.141.135 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 29953 => 94.207.141.135 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 10770 => 94.207.141.136 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 10770 => 94.207.141.136 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 4466 => 94.207.141.137 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 4466 => 94.207.141.137 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 27801 => 94.207.141.138 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 27801 => 94.207.141.138 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 14288 => 94.207.141.139 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 14288 => 94.207.141.139 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 11846 => 94.207.141.140 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 11846 => 94.207.141.140 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 42636 => 94.207.141.141 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 42636 => 94.207.141.141 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 7837 => 94.207.141.142 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 7837 => 94.207.141.142 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 62271 => 94.207.141.143 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 62271 => 94.207.141.143 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 6908 => 94.207.141.144 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 6908 => 94.207.141.144 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 29951 => 94.207.141.145 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 29951 => 94.207.141.145 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 10582 => 94.207.141.146 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 10582 => 94.207.141.146 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 61463 => 94.207.141.147 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 61463 => 94.207.141.147 80 Fri Feb 25 07:14:57 2011 TCP 188.40.98.54 32072 => 94.207.141.148 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 32072 => 94.207.141.148 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 31807 => 94.207.141.149 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 41404 => 94.207.141.152 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 6669 => 94.207.141.153 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 24449 => 94.207.141.172 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 24449 => 94.207.141.172 80 Fri Feb 25 07:14:55 2011 TCP 188.40.98.54 19439 => 94.207.141.173 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 19439 => 94.207.141.173 80 Fri Feb 25 07:14:56 2011 TCP 188.40.98.54 55637 => 94.207.141.174 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 55637 => 94.207.141.174 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 22382 => 94.207.141.175 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 25961 => 94.207.141.176 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 49493 => 94.207.141.177 80 Fri Feb 25 07:14:58 2011 TCP 188.40.98.54 10996 => 94.207.141.178 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 52247 => 94.207.141.179 80 Fri Feb 25 07:14:59 2011 TCP 188.40.98.54 26122 => 94.207.141.180 80 Fri Feb 25 07:15:00 2011 TCP 188.40.98.54 44654 => 94.207.141.181 80

14 27

Re: [tor-relays] Network Scan through Tor Exit Node (Port 80)
by Scott Bennett 08 Mar '11

08 Mar '11

I wrote: > On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris(a)eff.org> wrote: >>On Feb 26, 2011, at 9:53 AM, mick wrote: >> >>> No reputable security researcher would a) scan a network without that >>> network owner's explicit permission, nor b) use tor for that scan. >> >>Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet. > > Well, as I've just finished describing in another topic here, I treat >scanning of my system as attempted security breaches. Such scans will not >elicit any apparent response from my system, except that the scanner's >IP address will shortly be added to my "block" file, which will deny all future >access to my tor node's ORPort and DirPort. >> >>Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable. >> > I disagree and, as noted above, treat that as a cracking attempt. tor >nodes that you abuse in such fashion will continue to function by the means >described below, provided they are listed in the current consensus document. >My current procedures are described in the next two paragraphs. However, ^^^ Sigh. I added another paragraph ahead of those two and then missed changing the "two" to "three" above. Nothing of real consequence here, but I point my mistake out in case it was confusing to anyone before. >your implication quoted above that EFF has/does/will abuse tor exits in this >manner suggests I may have to modify my treatment of tor exits from which >your scans emerge, given the increased likelihood that the offenses did not >originate from the exit node's system and that the exit node was instead >a victim as well. Nevertheless, your scans will not get responses from my >system, except for connection attempts to the ORPort or the DirPort. > First, I have set the sysctl variable called net.inet.tcp.blackhole to 2, >which causes the kernel to drop all incoming packets addressed to closed ports. > The IP addresses of tor nodes, including exit nodes, listed in the >cached-consensus file on my system are placed into a "pass" file every 30 >minutes, which temporarily exempts them from being checked against the >"block" file. It is temporary in that the exemption lasts for 30 minutes >only, although it will be exempted for another 30 minutes whenever the >address exists in the cached-consensus file at the time the "pass" file is >rebuilt. > Anyone who may be concerned that their IP address or address range might >be listed in my "block" file is welcome to write to me to inquire about it. >If it is, then I will offer to remove the block on an indefinitely >probationary basis. However, if I encounter the same IP address in my pf log >again, then I will block the address permanently. > Frankly, I think it's appalling that a previous sponsor organization for >the tor project should turn on the tor network in the fashion you've confessed >here that it has. I'm tempted to dig out all of the EFF IP address ranges >and block them permanently, just as a matter of principle, although it would >obviously have little real effect upon your organization. No wonder so many >of us have run afoul of our ISPs when trying to run exit nodes when even EFF >is trying to spoil the tor network for us. Who needs enemies with "friends" >like EFF? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0