- tor-relays - lists.torproject.org

Setting up a relay
by Lalle Bralle 13 Jul '11

13 Jul '11

Anyone that has a very specific guide available to setting up a relay? I was thinking of doing this since I'm a firm believer in anonymity, I use TOR myself so might as well help the network and I have decent internet connection that is quite unused most of the time (100 Mbps down/10Mbps up). I was trying to follow up on that help section on the official site but it wasn't enough. There's a possibility the relay didn't work because of my router but I have opened the rights ports, tested by putting some limits and just testing some settings but not avail.

6 7

Bandwidth
by Tomas Sironi 07 Jul '11

07 Jul '11

Hi people. In the Tor manual, the next options are specified: * * * - BandwidthRate* - RelayBandwidthRate However i don't get to see the difference between those two. I imagined the first one is the bandwidth of tor being a client, and the second for the relay (server). But then i read this in the *BandwidthRate* description, breaking my previous supposition: ... If you want to run a relay in the public network, this needs to be *at > the very least* 20 KB ... I know those options limit the bandwidth but i don't know exactly which affects what. I'm running my Tor as client and relay, so i'm a little bit confused. Can anyone explain that for me? Thanks!

2 2

Relay Seccurity
by Tomas Sironi 05 Jul '11

05 Jul '11

Hi people. I'm new with Tor and i'm very interested in this project. I'm now being a relay, only acting as middleman (no exits). I would like to contribute more by having some services as exit. However i'm concerned about security. The machine i'm running as a relay is a pc in my home. From it, i have access to my router's web interface. The problem if i act as a exit for the port 80, would be that anyone can log into (or try to) my home router just by pointing to its ip address. Am i right? I've thought about using iptables to block outgoing connection from the relay to my router using iptables -A OUTPUT -d 192.168.15.1 -j DROP Not sure that's the correct line to do that. It blocks ping requests but i still can access the web interface of my router from that pc. Can anyone help me here? Thanks.

4 4

TOR on webOS?
by Bruno Kitzis 05 Jul '11

05 Jul '11

Good evening, I was wondering if TOR can be installed on WebOS? I was wondering because the OS family of webOS is Linux and TOR can be installed on LInux. But on your website it's written that TOR can only be installed on Android, iPhone and Maemo. Thanks a lot for your answer. Bruno Kitzis.

1 0

Registration for tor relay list
by Chris Boyd 03 Jul '11

03 Jul '11

thanks!

1 0

reg : Scripts / programs to monitor per stream statistics by a Tor client
by Sambuddho Chakravarty 24 Jun '11

24 Jun '11

Dear all Is there a script to monitor the per client statistics that a Tor client could use ? Thanks Sambuddho

1 0

migrate a tor
by Bruce Ganton 23 Jun '11

23 Jun '11

Hi all, I am new to this list and should probably lurk for a while to pick up the culture. However, I really want to know.... if it is possible to move/migrate a tor from one computer to another and retain the same identity. I assume this is necessary for the proverbial t-shirt but it would also obviate resetting my weather watch. Bruce

2 1

tor-relay+polipo+firefox much slower than TBB - why?
by swsnyder＠snydernet.net 23 Jun '11

23 Jun '11

I've got an established Tor 0.2.1.30 relay running on a (Linux/x86) machine on my network, and want anonymity while browsing on another machine. Sure, I could just download and run the Tor Browser Bundle (Linux/x86_64), but why? I'm already running Tor, so why not use it for my browsing? So I run Polipo 1.0.4 on the machine running Tor and just point my browser (Firefox) at Polipo by specifying Polipo as a HTTPS proxy. It works but it's slow. After a few weeks I download the current TBB and give it a try, and find that HTTPS browsing is noticeably more responsive than on my tor-relay+polipo+firefox config. I note the same performance difference over the course of a couple of weeks, so I know it is not just a fluke. Can someone tell me why that is? In my configuration both Tor and Polipo are running on a slowish 32-bit machine while the browser is running on a fast 64-bit system. With the TBB, all the software is running on the faster system. Still, though, I have to believe that it is the Tor network that would be the bottleneck in both configurations, not the CPUs. The TBB and my stand-alone Firefox are both of the same vintage, so it's not a matter of one browser just being faster than the other. Maybe my Tor relay is already pegged at the specified bandwidth limit? Hardly. Traffic through the relay averages about %25 of the bandwidth ceiling I set. (That's a topic for another message.) I would much rather be just another client on my Tor relay than to have a special browser. What do I have to do to get the TBB performance with a stand-alone tor-relay+polipo config? Thanks.

1 0

reg : Tor link padding using keepalive control messages
by Sambuddho Chakravarty 09 Jun '11

09 Jun '11

Hi All I read in the design documents of Tor that there is a control field named keepalive which may be used for link padding . Has anyone every used this field ? Thanks Sambuddho

2 2

Exit policy question
by George Gemelos 05 Jun '11

05 Jun '11

I recently had a dedicated server free up and decided to set it up as a Tor relay. It has 100Mbps unmetered traffic, so I thought it would be a good contribution. Right now I have it set up as a middle node, but I am considering possibly converting it to an exit node. Both my server and I are based in the US. I asked my hosting company about the possibility of running a Tor exit node and they said that they do not have a policy against it, but that if they get a lot of complaints they might set up and ACL on specific ports. So I really would like to reduce the probability of getting any complaints. I have heard about the reduced exit policy. What are people's experience running with that policy? Is there a further reduced set that might be better, in the sense of avoiding complaints, and still remain useful as an exit node? Should I just leave it as a middle node? Thanks in advance for any feedback. Regards, George

13 34

Exit enclaves load time
by Zach Lym 20 May '11

20 May '11

I have been running load time tests for duckduckgo.com and ff.duckduckgo.comthrough the Tor network. duckduckgo.com should be on an enclave node<https://www.dan.me.uk/torcheck?ip=72.94.249.36>, ff.duckduckgo.com should not be. But they appear to be loading at comparable times and LoadUI is showing no difference between the two URLs- even more complex queries such as "what is my IP" Can anyone tell if duckduckgo.com misconfigured? Is it the CDN that DuckDuckGo uses that equalizes the load time? Is the Tor network not utilizing the enclave node as heavily as the documentation makes it sound? Or have the exit proxies really gained that much capacity that they are no longer the bottleneck for such small small requests? -Zach Lym

3 4

Keep your Tor relays updated!
by tagnaq 16 May '11

16 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I encourage everyone running a relay to use an up to date Tor version. (especially directory authority operators - but they should know better anyway) This might be an obvious recommendation but there are a lot outdated relays (~15%). What are currently recommended Tor versions? You can find out by going to: https://metrics.torproject.org/consensus-health.html (go to "Recommended versions") 0.2.3.1 is also fine (atm). If you don't know what version you are using, run: tor --version If you are running an old version for a specific reason I'd like to hear about it (off-list if you wish). make the Tor network safer - update your relays. tagnaq PS: Next week I'll try to contact relay operators still running <0.2.1.29 <0.2.2.21 update if you want to help reduce the effort. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk3NhE0ACgkQyM26BSNOM7Z7qwEAtao1Z2CPl+GV8lhwG18sSA1N pFLqVQ4h/EmbzicMuAMA/1U59gNti+hs8wYUh8THXky+aKb7YIR7D0hokdpNcWBY =YTaA -----END PGP SIGNATURE-----

3 6

Difficulties in running a private Tor network
by joel hobson 16 May '11

16 May '11

Hi all, I hope this is the right place to ask for help with this problem. I'm working as a research assistant at a university for the summer, and my project requires me to set up a private Tor network. I'm attempting to run 3 dirservers on three different linux/unix machines. Most of the time, the dirservers upload their signatures to one another as they're supposed to, but I still have problems after that. I'll usually get messages like "Received http status code 404 ("Not found") from server 'IP:PORT' while fetching "/tor/status-vote/consensus-signatures.z"" (the 404s IP:PORT are always the same) or "[notice] While fetching directory info, no running dirservers known. Will try again later. (purpose 5)". Two of the dirservers give me messages saying "[warn] Configured authority type does not match authority type in DirServer list. Adjusting. (4 v 6)" when I start them up. I have little idea of what any of these errors mean, and no idea of how to fix them. My torrc files are mostly the same for each server, and I've pasted one below. I hope someone here can help me figure this out. Thanks, Joel TestingTorNetwork 1 DirServer dir1 v3ident=2D50FCA97045D078CD22E9092C9CF3E300084B87 orport=5151 x.x.x.x:5150 FD65 3AE1 4133 31A9 20DF 8220 1F6F 8DF7 268F F238 DirServer dir2 v3ident=EAC28AB68522174442AA214DC60C625675B2D1E9 orport=5152 y.y.y.y:5150 95B9 79E9 4A37 161C EFCC EE13 E7C5 D7EA EB76 B695 DirServer dir3 v3ident=24BD756B7660827D0507319A87DD16F31250A29C orport=5153 z.z.z.z:5150 23D5 E382 86E6 1118 48E9 C848 2ECE B702 23EA A0E8 DataDirectory . ORPort 5152 SocksPort 0 Address y.y.y.y DirPort 5150 V3AuthoritativeDirectory 1 AuthoritativeDirectory 1 ContactInfo test(a)test.test ExitPolicy accept *:* AllowSingleHopExits 1 ExcludeSingleHopRelays 0

4 5

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

05 May '11

On Fri, 15 Apr 2011 04:12:53 -0700 Mike Perry <mikeperry(a)fscked.org> wrote: >Thus spake Scott Bennett (bennett(a)cs.niu.edu) > >> On Sat, 02 Apr 2011 Jacob Appelbaum <jacob(a)appelbaum.net> > wrote: >> >> On Thu, 10 Mar 2011 10:27:50 -0800 Chris Palmer <chris(a)eff.org> wrote: >> >>> >> >>> The Observatory work was not done through Tor. >> >>=20 >> >> Good. >> > >> >I think we need a scan of the SSLiverse through Tor. >> >> Use !=3D abuse. >> If I run sendmail with it configured to accept mail from outside, th= >at >> does not mean I agree to receive massmail, malware, or other bad stuff via >> TCP port 25. Because various idiots with access to the Internet insist u= >pon >> attempting to abuse my ability to receive mail does not militate against = >my >> defending my system from such malicious activity in any way I see fit. > >You are right. It does not. You are entitled and in fact expected to >defend your system from scans and abuse. > >Censor yourself, not others. Laying aside for the moment the definitional problem with your demand that I am neither a state nor an employee of one, I think you have gotten me mixed up with someone else. I have never advocated censorship. You perhaps have forgotten the many instances in which I have requested a BadExit flag be assigned to exit nodes that altered the data returned to tor streams from the destinations or that reliably "failed" to connect to certain destinations when other exit nodes did connect to them. I have, OTOH, stated approximately my policy regarding inappropriate attempts to probe or otherwise access my computer. If you see some connection between my denial of access to my ORPort and DirPort to systems I deem to be miscreants based upon their own past behavior and the administration of an exit node, then please enlighten me because my understanding hitherto of the design of tor was to render untraceable any relationship between the two, which would seem to me to require that entry node access restrictions have no relationship to exit restrictions. >=20 >> Further, an activity that can be used by one party to cause terminat= >ion >> of another, innocent party's Internet connection is an intolerable assault >> upon the latter party's paid access to the Internet for all purposes, not >> just to offer additional capacity to the tor network, and upon a private >> agreement between the latter party and his/her ISP. Defense against such >> offenses is completely appropriate and in order. > >It is not an arbitrary party whose Internet connection risks >termination. It is a party that signed up to protect Internet freedom >and resist censorship. People who want to bring censorship to Tor are >not welcome on the network. The reason is simply because censorship >does not work. True enough, though irrelevant to the discussion of entry node access. > >> The activity in question also is not easily distinguishable from that >> of a lot of actual malware that scans for open ports to find a way in. > >This justifies Internet censorship? Or censorship at Tor Exits? It seems that I am not the only one who has misplaced some details here. I cannot remember ever having advocated filtering of exit traffic in any way other than by published exit policy. In fact, I have even once asked for a BadExit flag for a node that returned bad data that it itself may have received from some intermediating proxy on grounds that the data were still not what should have been returned. (That was the time that grarpamp objected on grounds that it might not have been the exit node's fault, even though the data were still bad.) I note here again, non-state entities might filter, but by definition, are not censors because they only exert control over their own property, as opposed to state entities that do violate the property rights of others by forcibly exerting control over the private property of others in order to restrict or adulterate the transmission of information. > >Or are we just trying to ethically define "abuse" and "anything that >looks like malware" is the best we've come up with so far? That's >a pretty poor standard. I define it as TCP SYN or UDP packets sent to ports on my system on which no program is listening, which is the same as saying that they are attempts of unauthorized access. > >> >Google seems to have this data from crawling the web and simply caching >> >it as a matter of crawling everything - they get the data from lots of >> >sources such as other urls, toolbars, etc. Google recently published >> >the Google Certificate Catalog: >> >http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certifica= >te-security.html >> > >> >So is Google's method the only ethical way to collect this certificate >> >data? Or is there no method for collecting this data without users >> >manually submitting each certificate they encounter by hand? >> >> AFAIK, Google does not use the tor network for its web (or other) >> crawling activities. For Google's purposes, the tor network would be >> unusably slow. AFAIK, Google does not use any method that uses someone >> else's computer(s) to make its connections to a destination.=20 > >What does using the Tor network have to do with the ethics of crawling >the web/Internet? What makes it not OK to crawl the Internet >anonymously, but makes it acceptable to seek that same information so >long as you are not anonymous? Or are we being Kantian here, and >saying that if everyone crawled the Internet, we'd be doomed. So >therefore, only Google can crawl the Internet? That doesn't work >either. The problem, as I hoped I had made clear already, is that it incites damage to the tor network, specifically to both the population of tor exit nodes and their operators' Internet access. Google, AFAIK, does not use tor and therefore does not place tor exit nodes at risk. > >Again, people sign up to be Tor relays to take a stand against >Internet censorship and surveillance. It is thus expected that they >allow all traffic to pass unmolested and unmonitored, or work to >implement a way to do their programmatic ExitPolicy filtering in a way >that does not impede client activity. > >Exits are not so scarce that we need to flex our morals on this point. I am not going to get into a discussion of morals because morals vary from one person to another based upon anything from religion to culture to personal whim. I limit my discussion to points of ethics, which are invariant and can therefore be addressed with consistency. > >> An EFF employee, OTOH, has confessed to doing so on this list. The >> latter, then, is burning CPU time, as well as network connection >> throughput capacity, on not just one system, but on routelen + 1 >> systems for each scanned system times the number of ports scanned on >> that system. > >Nobody confessed to doing anything over Tor. Chris and Jake simply >defended the idea of crawling the net over Tor. At no point did >anybody state that the scan did happen over Tor. In fact, several >people said the opposite. > You are correct in this matter. I misremembered that detail, and I apologize for my misstatement. Nevertheless, Chris, IIRC, did say that he supported such abuse of tor exits, even though he had not (yet) done so himself. >Perhaps if your mail client supported threading this would be more >apparent to you? Actually, it's right there in the very first text you No, it has nothing to do with mail software, as you observe in your next sentence. >quoted, though. So perhaps something else is amiss. Is the pager in >UNIX 'mail' still the original 'more' or something? Or are you still less(1). >using 'ed' to type your mails? :) The problem was (and still is, though less so already) the delay in catching up to current mail due to an immense backlog in my in box. Ever since I unsubscribed from tor-talk several weeks ago, I have slowly been gaining ground on the extent of the running backlog, so the situation can be expected to improve over time. My apologies for my confusion. > >> Another point, though irrelevant due to the ethical considerations >> that we've been discussing so far, is that there is no particular >> reason to use tor rather than some other proxy to look at the >> Internet from different locations. Anonymity is not necessary to >> achieve that end. > >It is very useful to be able to scan the Internet from multiple, >stable vantage points with anonymity. That seems likely true. However, it doesn't justify doing damage to third parties, who have committed no offense other than to offer a service to a community of users who desire to access the Internet anonymously, nor to that community of users by reducing the size of the pools of exit nodes and of any other circuit positions in which those same nodes may serve. > >So long as the resources of any one site are not unreasonably >consumed, and so long as the scanner is not substantially occupying Tor >exit bandwidth, I really don't see what is so ethically complicated >about this.=20 As noted before, the ethical problem is that exit nodes are put at much greater risk of elimination. I realize full well that there are plenty of other tor users who act in similarly damaging ways for actually nefarious ends, but the point remains that the means are wrong, regardless of the ends. > >By occupying this topic with our attention, we are allowing ISPs who >seek to impose restrictions on Tor traffic in one form or another to >have their way and dictate what is acceptable on our network. Such I would be interested to know what evidence you have to support that claim. From what I've seen thus far, ISPs, especially gigantic ones like Comcast, have not the slightest interest in which programs one runs, much less the often esoteric discussions on mailing lists related to those programs. Instead, they care about dividing their services into two classes: one class that is relatively cheap but is definitely *not* a full-service for Internet access and another class that costs at least twice as much and usually provides something approximating full Internet access. In the U.S., the partial service has sometimes been falsely, and therefore illegally, advertised as "full Internet service" or "unlimited Internet access/service". >ISPs do not deserve any Tor-related revenue. Agreed. However, in many locations there is no or greatly restricted competition, often due to governmental intervention, so the individual subscriber's options may be limited to either working with such degenerate corporations or not being connected to the Internet at all. > >It is that simple. We can worry about compromising our principles for >precious few kilobits when all else has failed. > If you are so willing to compromise on principles, then why do you devote your professional life's work to the tor project? Do you secretly aim to undermine the goals of the project in some way? After all, you recently opined that exit nodes with throughput capacities less than 100 kB/s were basically a nuisance and/or not worth bothering with, just caused load distribution problems, and so forth, an opinion discouraging volunteers from running such exits. If that discouragement were to succeed in reducing the size of the exit pool, that would seem to reduce the anonymity of tor users correspondingly, something that would also seem in order for someone trying to sabotage a project for which he worked. I trust that wasn't your real intention, but it surely could have been interpreted that way by someone outside your inner circle. I was astonished when I first read it. 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

Relay behind firewall
by tagnaq 28 Apr '11

28 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, is there a way to properly configure a relay (ORPort reachable) that has full internet access beside outgoing destination port 80 that will properly work? Problems: publishing descriptor to authorities that use that port, clients are not aware of this restriction of a relay and will try to build circuits where $nextrelay uses ORPort 80 -> circuit will fail (currently 28 relays use ORPort 80) I guess one should simply not bother trying to run a relay in such a scenario. Is my assumption correct? thanks, tagnaq ps: FascistFirewall is for clients only -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk25Zg4ACgkQyM26BSNOM7YjMQEAlldmzhXeGbaar0tT0Qvyh3b+ b4cOSdVU3+x1iBPujqcA/0UiLBmGloriq5DJNOqXWQdO9dKIjOxW2zdewiTyNRm/ =sxNK -----END PGP SIGNATURE-----

2 1

DMCA notices in Canada?
by anarcat 26 Apr '11

26 Apr '11

Hi, Have any other tor operator *in Canada* been targeted with DMCA takedown notices? We have received a bunch from our upstream provider and so far have refused legal responsability because (a) we're not in the US and (b) there's nothing to takedown, we're just a transit provider... But now our upstream is threatening us to completely disconnect us if we do not take action within 30 days. We're running a full exit node, so it's likely getting used by people for bittorrent downloads... Ideas? Suggestions? Legal support? United organised legal front? A. -- Imagination is more important than knowledge - Albert Einstein

2 3

Persistent XSS vulnerability in TorStatus
by tagnaq 23 Apr '11

23 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "TorStatus is a website display used to summarize metrics about the Tor Network. It's a precursor to http://metrics.torproject.org. The code repository is at https://svn.torproject.org/svn/torstatus/. Example running sites are http://torstatus.blutmagie.de/ [...]" Note: TorStatus is not a Tor Project product and is not maintained. Vulnerability - ------------- DisplayRouterRow() in index.php prints the contact information string from a server descriptor - defined via 'ContactInfo' in torrc by a node operator - into the HTML page without proper output encoding. This leads to a persistent cross-site scripting vulnerability where every Tor node operator can insert HTML/JavaScript on all vulnerable TorStatus mirrors. The contact information column is only included in the HTML page if the end-user (browsing a TorStatus mirror) adds the contact column via "Advanced Display Options" (column_set.php), the contact column is not included by default. An attacker might set the displayed columns for a victim via CSRF. A simple search in the server descriptors of the last two months did not reveal an obvious exploitation in that time period. The simple search used is not suitable to give a clear answer. [grep -hir ^contact * |egrep -i '(script|src)'] Affected Versions - ----------------- 4.0 3.6.1 3.6 3.5 3.4.2 3.4.1 and probably others Solution - -------- The attached patch was committed to the svn (revision r24666). https://svn.torproject.org/svn/torstatus/ Thanks to Robert, Andrew, Olaf, Damian and Sebastian. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk2zBb4ACgkQyM26BSNOM7YE8gD9HzwAZ1rfUDM+GLxjFfo0o1R7 A5l2MPddbmPlr+d23oYA/1m8VI3bbG9RXvao453j2Yyqix/iJ01rJbLP63PtWShw =Ay2T -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] high cpu usage, normal ?
by Scott Bennett 21 Apr '11

21 Apr '11

On Tue, 5 Apr 2011 14:56:42 +0200 Gijs Peskens <gpeskens85(a)gmail.com> wrote: >I'm running an exit relay configured to give up to 6,4MB/s on an Athlon64 >3000+ Freebsd box, and I'm seeing cpu usage between 30-60% is this >considered normal ? Any means of getting it down? (except getting a faster For such a high-throughput node on such an old CPU, yes, that is not only normal, but actually quite low CPU usage. >cpu or hardware crypto) I don't remember whether the 3000+ is a K10-type CPU or later. If it is, then make sure you have superpages support enabled in your kernel at boot time. If the 3000+ is pre-K10, then enabling superpages support is as likely to hurt performance as it is to help it, which basically would leave you the option of trying it both ways to see which worked better for you. On a K10 or later style of CPU, running a high-throughput node with superpages enabled should shave 10% to 30% from whatever tor's current usage. IOW, if you're seeing 30% - 60% now, then what you see with superpages enabled would probably fall into the 21% - 54% range. The problem with AMD's pre-K10 CPUs is that the size of the TLB shrinks when 4 MB pages are used, so that instead of having 64 entries for text pages and 64 entries for data/stack pages, there are only two (maybe just one--I don't recall for sure) entries for each. Because tor is a much larger process than would fit into one 4 MB page of each kind, using the 4 MB page size instead of the 4 KB page size is very likely to drastically increase the frequency of full address translations, rather than reducing it as on later CPUs in which the TLB retains the capacity for both page sizes. To enable the use of superpages, your system must be at 7.2-RELEASE or later of FreeBSD. Just add the following to /boot/loader.conf, and then reboot. # enable superpages (4 MB) for large processes vm.pmap.pg_ps_enabled=1 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

Tor and Viruses
by Porcelain Mouse 17 Apr '11

17 Apr '11

Greetings All, I've been running an exit for about 5 months, but had to stop due to virus abuses. In the last two weeks, my ISP has partially blocked my Internet access twice due to suspected virus infections. I'll spare you the long story, but I was able to get a copy of their "evidence" and I'm fairly certain it was connections made through my Tor relay. 1) How common is it that Tor is abused by viruses? What is the trend? 2) Is this just standard virus-kit material, these days? I guess I was a little surprised. Obviously, this is a great idea for hiding the infection site, so I'm sure it's being done. But still, I've been fighting viruses for quite a while and I don't think I've read a single virus description that mentioned Tor. I'm sure it's happening, but I've never heard a single statistic about it, so I thought I would ask. Also, this type of abuse is *not* mentioned on the Tor wiki's Abuse FAQ under "What should I expect if I run an exit relay?" I read that section carefully and was prepared for most of the things mentioned. Again, I'm not completely shocked. I'm just saying it didn't seem likely, according to the FAQ. It would be nice to know how likely is this kind of abuse, and what is the trend. (And, maybe someone can add the results to the FAQ when we have an answer.) Thanks, PMouse

7 7

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

15 Apr '11

On Sat, 02 Apr 2011 20:08:16 -0700 Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >On 03/29/2011 02:10 AM, Scott Bennett wrote: >> On Thu, 10 Mar 2011 10:27:50 -0800 Chris Palmer <chris(a)eff.org> wrote: >>> On 03/10/2011 09:10 AM, mick wrote: >>> >>>> 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." >>>> >>>> Which says to me that you are using Tor to do this research. >>> >>> No, it says to you that 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. >>> >>>> So which is it? >>> >>> The Observatory work was not done through Tor. >> >> Good. > >I think we need a scan of the SSLiverse through Tor. > >>> >>> However, 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, so I vociferously defend the idea of doing so. >>> >> Ah. "The ends justify the means." How enlightened. :-( >> > >I don't think Chris is making "The ends justify the means" as his >ethical model. Tor relays with exit policies that allow exiting to *:443 Whether he is or is not using that as his "ethical model", that is indeed the form (see above) of his reasoning for defending the activity in spite of the harmful effects it has upon the tor network. >intend to allow exiting to *:443. You have to go to quite a bit of >effort to become a relay, so I'll trust that this counts as consent for >exiting the Tor network on port 443. I hope we don't disagree about this? Use != abuse. If I run sendmail with it configured to accept mail from outside, that does not mean I agree to receive massmail, malware, or other bad stuff via TCP port 25. Because various idiots with access to the Internet insist upon attempting to abuse my ability to receive mail does not militate against my defending my system from such malicious activity in any way I see fit. Do you suppose, for example, that the operators of the root name servers would hesitate for a minute to filter out packets from any address that were obviously attempting a DoS attack upon their root servers? And would they be wrong to do so? Consider that, in doing so, they would not only be defending their own services, but also the proper functioning of the entire Internet. The same reasoning applies to operators of exit nodes wishing to defend the continued existence of their nodes and thereby defend also the proper functioning of the tor network. > >Now, if your ethical issue surrounds the fact that they then connect to >a computer without asking permission, I'd make the argument that this is >reasonable. Even if I was mistaken in your desire to have me connect to >your system, I believe your placement of a computer system on the public >internet requires handling a little bit of expectation setting. > >What do I mean? I mean to say - if you configure PF to block me, I'm >still burning some amount of CPU time on your machine. Is that an >unethical action on my part? To ask your computer a question and for >your computer to reply (with say, a RST) is a normal part of the >networking protocols. The internet is inherently chatty and some amount >of that chatter is the cost of connecting to the public internet. >Obviously 1,000,000 connections at once isn't polite but is polite >really zero connections? Is one connection really so impolite or unethical? Your analogy is not valid. The activity in question can and does result in termination of services to exit nodes by their ISPs. > >Now - if we assume that it's reasonable to send a single SYN and then >complete the handshake when the policy allows, what is the next >boundary? I'd argue that common HTTPS ports probably run HTTPS software >- to better understand that software, you'll need to negotiate some or >all of that protocol. Is sending a TLS ClientHello a reasonable and >ethical next step? I'd say so. It also seems to make sense that when the >server replies, you might log the ServerHello. You might even log all of >the data that the server intended you to have. Is that impolite or >unethical? Is there something wrong with what has been done by this >point in the protocol? I don't think so. As noted above, the activity under consideration results in the general depletion of exit nodes from the tor network. Therefore it must be thought of as an attack upon the tor network itself. Further, an activity that can be used by one party to cause termination of another, innocent party's Internet connection is an intolerable assault upon the latter party's paid access to the Internet for all purposes, not just to offer additional capacity to the tor network, and upon a private agreement between the latter party and his/her ISP. Defense against such offenses is completely appropriate and in order. The activity in question also is not easily distinguishable from that of a lot of actual malware that scans for open ports to find a way in. Using an efficient packet filter (e.g., pf) is a way to provide a defense at minimal cost. Consider it similar to keeping one's household appropriately armed against intruders. Yes, security costs a bit, but TANSTAAFL, and like insurance, it's cheaper than not being prepared when an attack comes. In the case of using a packet filter to prevent responses to miscreants on a permanent basis, it has the additional benefit of proactively defending all other present or future services offered, while denying said miscreants any information. This is even more the case when the filter is combined with something like FreeBSD's black hole option for incoming packets for closed ports because the sender doesn't get a response even in the first attempt. That means that the delay in adding the sender's IP address to the filter does not allow the sender to receive any information at all in response, even once, except in the case that the sender happens to connect to a port that actually *is* open before the sender's address gets added to the table. > >Now the client will reasonably tear down the connection as described in >the relevant protocols. Is that wrong? I don't think so - the protocols >specifically indicate how systems should signal their intentions. You're >free to tell me to stop connecting and I'm free to connect - that's how >these things generally work. Let's apply that argument to telephones. There is a procedure for making a telephone call that has several steps: dialing, waiting for the switching system to establish a circuit, ringing the phone at the other end (a connection attempt), possibly several times, then either getting an answer or giving up on the connection attempt with no answer or because the response was a busy signal or notification that the number is no longer assigned. If the call is answered, then information may be transmitted in both directions, and eventually the connection is closed (hung up). So there is a protocol for making a phone call. The existence of the protocol can hardly be a justification for abuse. Is it okay to dial phone numbers, either at random or according to some desired pattern, just to find out whether a human answers, a modem answers, or there is no answer, only to disconnect immediately upon an answer or after an error indication or else upon a configured timeout? > >Now - as it happens, the EFF SSL observatory client does not actually >implement the entire set of SSL/TLS protocols - just as some software >does not implement TLS 1.1 or 1.2 - is it somehow wrong to run a client >that isn't completely implemented for all specs that it might encounter? >That seems doubtful. Again, pf's "synproxy" is an appropriate, preconfigured response of the target. It's kind of a simple version of a honeypot. > >Google seems to have this data from crawling the web and simply caching >it as a matter of crawling everything - they get the data from lots of >sources such as other urls, toolbars, etc. Google recently published >the Google Certificate Catalog: >http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-… > >So is Google's method the only ethical way to collect this certificate >data? Or is there no method for collecting this data without users >manually submitting each certificate they encounter by hand? > >Even if we pretend that the EFF or the Google methods weren't to be used >- do you think that the EFF model is actually burning more CPU time on >each system? AFAIK, Google does not use the tor network for its web (or other) crawling activities. For Google's purposes, the tor network would be unusably slow. AFAIK, Google does not use any method that uses someone else's computer(s) to make its connections to a destination. An EFF employee, OTOH, has confessed to doing so on this list. The latter, then, is burning CPU time, as well as network connection throughput capacity, on not just one system, but on routelen + 1 systems for each scanned system times the number of ports scanned on that system. > >Do you accept that there is some amount of CPU time you're going to have >to burn when you connect to the internet as a server? If so, what's the >limit or the edge of reasonable CPU time that a single client may cause >for a public server? Are you asking about reasonable time for service requests from legitimate clients? Or, instead, about reasonable time for ignoring "excommunicated" miscreants? > >In any case, the idea of using Tor for perspective routing is not >particularly new - Geoffrey Goodell's work on the topic is well over >half a decade old at this point. It makes a lot of sense to use Tor as a >perspective-routing system of sorts and there's nothing wrong with that >at all. > The problem has now been identified and publicized. If EFF can find some non-damaging alternative method to gather the information it desires, then more power to it. In the meantime, it should cease any and all activities that can damage the tor network or that can adversely affect innocent parties elsewhere. Ethics do matter. Another point, though irrelevant due to the ethical considerations that we've been discussing so far, is that there is no particular reason to use tor rather than some other proxy to look at the Internet from different locations. Anonymity is not necessary to achieve that end. BTW, I was offended to read a day or two ago that you had been subjected to still more harassment by the federal crime syndicate when returning to the U.S. from points south recently. You certainly have my sympathy over such injustices. The best hope at present is, I think, that the empire will soon bring on its own collapse under the weight of its theft of wealth by inflation when the largest buyers of T-bonds stop buying them. Keep your chin up and your eyes on that day. :-) 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 * **********************************************************************

3 2

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 11
by Gijs Peskens 14 Apr '11

14 Apr '11

My ISP also send me a message about abuse (virusses) ,and after I send them a reply that I'm running a tor node and that if they receive further abuse complaints they should just forward them to my mail for me to handle myself I didn't receive any abuse mail again :) I think my ISP is actually running some IDS with sinkholethinghies (I don't know anything about IDS'es yet, will research into it) and I can access a page with info on my IP wich shows some activity: 2011-04-05 21:56:55,85.223.49.156,29272,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,2000 SP2+, XP SP1+ (seldom 98) 2011-04-05 22:26:35,85.223.49.156,45924,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Windows,2000 SP4, XP SP1+ 2011-04-04 21:04:06,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-05 02:29:02,85.223.49.156,20507,NL,GET /?REMOVED HTTP/1.0,sality,KUKU v5.02c =REMOVED,,30184,Windows,2000 SP4, XP SP1+,,80,www.REMOVED.info,,,,REMOVED,8560,... 2011-04-05 22:02:01,85.223.49.156,20507,NL,GET /search?q=0 HTTP/1.1,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .N... 2011-04-06 01:13:53,85.223.49.156,20507,NL,.,downadup,,,21901,,,,80,,,,,REMOVED,US 2011-04-07 20:08:37,85.223.49.156,20507,NL,GET /tatoshko.biz?data=REMOVED== HTTP/1.0,machbot,MachBot,,10988,Windows,2000 SP4, XP SP1+,,80,853c9e57.biz,,,,87.10... 2011-04-11 16:46:41,85.223.49.156,47015,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,US,,1,,,Linux,2.6 (newer, 2) 2011-04-11 15:31:23,85.223.49.156,20507,NL,GET /search?q=15 HTTP/1.0,downadup,Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727),,45931,Windows,2000 SP... 2011-04-12 04:08:30,85.223.49.156,44022,20507,NL,UTRECHT,AMERSFOORT,,tcp,sinkhole,,,REMOVED,DE,,1,,,Windows,XP/2000 REMOVED= ip adresses (destination), dns names or things that look like http session specific things. I see one port number (destination) somewhat more (all cases of tcp,sinkhole except 1): 8560 might be a virus/trojan/worm specific port ? Might be a good idea to remove this port from your exit if you get a lot of complaints (and it's not used for anything usefull) The idea of setting up a local smtp out server with spam detection and clamav seems like a very good idea, maybe together with some tarpitting (if possible and easy) it would help a lot of users in need of smtp access and deter spammers (as they would spend hours and hours in tarpits at random when using tor) anyone can provide some good advice on how to set it up properly (I'm running FreeBSD)? Would also be _really_ nice to maybe somehow add some header that says it was send using a tor relay with admin details so my ISP (as I would probably need to set it to relay to their smtp) will not start bitching and moaning about that to me, is it possible ? Yes? How ? ;) What are the dangers of running an IDS myself ? Privacy wise I mean, could it be set up so that it knows about bad stuff hapening and in no way log other stuff ? 2011/4/13 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Tor and Viruses (Porcelain Mouse) > 2. Re: Tor and Viruses (grarpamp) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Apr 2011 20:46:21 -0700 (PDT) > From: Porcelain Mouse <porcelain_mouse(a)q.com> > Subject: [tor-relays] Tor and Viruses > To: Tor-Relays <tor-relays(a)lists.torproject.org> > Message-ID: <alpine.LFD.2.02.1104122018100.5770(a)localhost.localdomain> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > Greetings All, > > I've been running an exit for about 5 months, but had to stop due > to virus abuses. In the last two weeks, my ISP has partially blocked my > Internet access twice due to suspected virus infections. I'll spare you > the long story, but I was able to get a copy of their "evidence" and I'm > fairly certain it was connections made through my Tor relay. > > 1) How common is it that Tor is abused by viruses? What is the trend? > 2) Is this just standard virus-kit material, these days? > > I guess I was a little surprised. Obviously, this is a great idea for > hiding the infection site, so I'm sure it's being done. But still, I've > been fighting viruses for quite a while and I don't think I've read a > single virus description that mentioned Tor. I'm sure it's happening, but > I've never heard a single statistic about it, so I thought I would ask. > > Also, this type of abuse is *not* mentioned on the Tor wiki's Abuse FAQ > under "What should I expect if I run an exit relay?" I read that section > carefully and was prepared for most of the things mentioned. Again, I'm > not completely shocked. I'm just saying it didn't seem likely, according > to the FAQ. It would be nice to know how likely is this kind of abuse, > and what is the trend. (And, maybe someone can add the results to the FAQ > when we have an answer.) > > Thanks, > PMouse > > > ------------------------------ > > Message: 2 > Date: Wed, 13 Apr 2011 03:19:27 -0400 > From: grarpamp <grarpamp(a)gmail.com> > Subject: Re: [tor-relays] Tor and Viruses > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTikwPS6JDqKMvaxxWhgq2dUoGELKKA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > my ISP has partially blocked my Internet access twice > > due to suspected virus infections. > > Virus is likely not the right word for things. Anyways... > > There's really no reason an operator cannot run something > like bro-ids.org and sink known bad traffic in real time. Yeah, > sure, everyone will bitch at me. But it is operator fiat, and > they're not sinking specific users, so well within common > carrier exceptions on that aspect. No different than operators > who block 'torrent' ports, smtp, etc. > > Speaking of smtp, one could even redirect that into their > system despam/clamav it and send it on its way. Better > than nothing. Especially for the legit senders. > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 3, Issue 11 > ***************************************** >

2 1

Re: [tor-relays] tor-relays Digest, Vol 3, Issue 9
by Ray Waren 12 Apr '11

12 Apr '11

I have problems connecting to the tor network always stuck at "Authenticating to Tor". I ask for assistance in what I should try to get in touch with tor again. Thank you. 2011/4/11 <tor-relays-request(a)lists.torproject.org> > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: two relays serving same hidden service (prafull moulekhi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Apr 2011 23:59:08 +0530 > From: prafull moulekhi <prafullmoulekhi90(a)gmail.com> > Subject: Re: [tor-relays] two relays serving same hidden service > To: tor-relays(a)lists.torproject.org > Message-ID: <BANLkTi=G8-OyQsz0rr38=PJWHNb7bgwCOA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi > my tor is not working.It's logs show "No certificate available" > > please help > > Prafull >

2 1

two relays serving same hidden service
by cmeclax-sazri 10 Apr '11

10 Apr '11

Suppose I have this setup: Dhole, Dingo, and Fennec are three computers on a LAN. Dhole and Dingo both have external IP addresses and both run Tor relays. Fennec runs a hidden service. Both Dhole and Dingo have the same hidden service address, paxamifrabolerfu.onion, pointing to Fennec's LAN address. Alice tries to connect to paxamifrabolerfu.onion. What happens? cmeclax

3 2

avoiding frequent MyFamily syncing on a dynamic Tor instance group
by tagnaq 08 Apr '11

08 Apr '11

Hi, I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes: To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones. >From a security point of view this is probably quite a bad thing, but does someone already do that?

4 4

Re: [tor-relays] Request for help - Tor legal FAQ
by Marcia Hofmann 07 Apr '11

07 Apr '11

>> To make the FAQ as current and useful as possible, we want to make >> sure that we know about any legal issues that relay operators in the >> United States may have experienced over the past few years. > I understand the focus on USA, but wouldn't this be a good opportunity > to add legal information about other countries as well? It's fantastic idea, and we'd love to be able to do it. Unfortunately, all of our practicing lawyers are licensed in the United States, and we don't have the legal expertise to provide an FAQ like this on a country-by-country basis. :(

3 3

high cpu usage, normal ?
by Gijs Peskens 06 Apr '11

06 Apr '11

I'm running an exit relay configured to give up to 6,4MB/s on an Athlon64 3000+ Freebsd box, and I'm seeing cpu usage between 30-60% is this considered normal ? Any means of getting it down? (except getting a faster cpu or hardware crypto)

3 2

help w/ Debian: Error binding network socket: Address already in use
by Olaf Selke 04 Apr '11

04 Apr '11

Kernel 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux Tor v0.2.2.23-alpha (git-b85eb949b528f4d7) Hi folks, on blutmagie exit Tor frequently logs Apr 04 15:27:48.706 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.765 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.775 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.785 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.864 [warn] Error binding network socket: Address already in use Apr 04 15:27:48.900 [warn] Error binding network socket: Address already in use I'm a little bit clueless what's wrong here. I've read http://hea-www.harvard.edu/~fine/Tech/addrinuse.html and found SO_REUSEADDR being used in connection.c. Tor opens about 1k new tcp connections/s and the average number of open tcp sessions is about 70k. anonymizer2:/tmp# netstat -tn | wc -l 70597 Any ideas why Tor can't bind to sockets? regards Olaf

2 2

Request for help - Tor legal FAQ
by Marcia Hofmann 04 Apr '11

04 Apr '11

Hi there, EFF is updating the Legal FAQ for Tor Relay Operators, which we first wrote about six years ago. https://www.torproject.org/eff/tor-legal-faq.html.en To make the FAQ as current and useful as possible, we want to make sure that we know about any legal issues that relay operators in the United States may have experienced over the past few years. To that end, does anyone on this list know about situations where... ...a relay operator has been sued or prosecuted for anything Tor-related? ...the police have seized servers that are running relays? ...someone has tried to use a legal demand (like a subpoena) to figure out who operates a relay? Please email me off-list if you know about an incident like this or anything else you think I should be aware of. Many thanks for your help! -- Marcia Hofmann, Senior Staff Attorney Electronic Frontier Foundation 454 Shotwell Street San Francisco, CA 94110 tel: (415) 436-9333 x. 116 | fax: (415) 436-9993 marcia(a)eff.org | http://www.eff.org

3 2

circuits that fail the exit policy repeatedly
by Scott Bennett 03 Apr '11

03 Apr '11

Upon occasion, I see very long sequences of info-level log messages to the effect that an exit stream has failed the exit policy. Is there any good reason why a relay should not return a DESTROY cell on a circuit whose exit connection attempts have failed the exit policy some threshhold number of times? After all, the exit policy is published information. Anyone making repeated attempts to violate it is either doing so in ignorance of a recent change to the exit policy, perhaps not yet propagated to the client causing the problem, or is doing so as some sort of cracking attempt. It seems to me that killing a circuit in this situation is appropriate to minimize waste of tor network resources. Any thoughts on this? 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

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

03 Apr '11

On Thu, 10 Mar 2011 10:27:50 -0800 Chris Palmer <chris(a)eff.org> wrote: >On 03/10/2011 09:10 AM, mick wrote: > >> 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." >> >> Which says to me that you are using Tor to do this research. > >No, it says to you that 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. > >> So which is it? > >The Observatory work was not done through Tor. Good. > >However, 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, so I vociferously defend the idea of doing so. > Ah. "The ends justify the means." How enlightened. :-( 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 * **********************************************************************

2 1

Tor not releasing port on shutdown?
by Geoff Down 02 Apr '11

02 Apr '11

Hi, the most recent times I have tried to restart Tor after a 'killall -INT' I have been presented with the following error: "[warn] Could not bind to 0.0.0.0:9001: Address already in use. Is Tor already running?" I'm not sure if this has started since I changed version, I'm on Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) OSX 10.3.9 . Anyone else see this? How do I release that port? Command 'lsof -i' returns no results, so I don't see Tor is really using it still - no sign of Tor in command 'ps -aux' output. Update: after running those commands, Tor was able to start. Why the delay? Is this normal? TIA GD -- http://www.fastmail.fm - The professional email service

5 5

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

30 Mar '11

On Wed, 9 Mar 2011 19:18:34 -0500 cmeclax-sazri <cmeclax-sazri(a)ixazon.dynip.com> wrote: >On Wednesday 09 March 2011 17:20:17 Chris Palmer wrote: >> On 03/09/2011 01:48 PM, Arjan wrote: >> >> We are saying hello on port 443, and then saying goodbye. Once. Using >> >> normal TCP and TLS handshaking, no tricks. For the good of the internet. >> > >> > That would be enough to get me in trouble with my ISP for performing >> > portscans (if I were running an exit node). >> >> And how would you, or anyone else, differentiate that from normal web >> browsing? > >If a lot of those connection attempts are going to IP addresses with no host >present, or hosts not running a webserver, it looks like portscanning. If >almost all of the connection attempts are to webservers that have port 443 >open, it looks like normal https web browsing. Are you kidding? Closing a connection upon receipt of the ACK response to the SYN you sent looks like normal HTTPS web browsing? On what planet? Normal web browsing, whether HTTP or HTTPS, involves data transmission occurring in both directions between receipt of that ACK and the closing of the connection by the web browser. Closing the connection upon receipt of the ACK response to the SYN without any intervening data transmission is, OTOH, a characteristic behavior of port scanners. So you had it backwards. Here's a tidbit for you to consider. pf offers an option on filtering rules for inbound SSL connections called "synproxy", which relieves server software of the effort of dealing with bogus connection attempts by handling the SSL exchanges itself before passing the connection on to the server. It also means that a connection from something that doesn't know how to perform the SSL handshaking will sit until the timeout occurs, so the attacker is stuck with an outstanding connection tying up resources until that happens. That delay of a couple of minutes can be a long and wasteful nuisance to an attacker. OTOH, a legitimate application, e.g., a tor client or relay trying to connect to the ORPort of another relay, completes the handshake and begins communicating with its peer with no delay, and the software accepting the connection only deals with the legitimate connections. It works just great! :-) I highly recommend it to anyone running a tor relay on a system that supports pf. > >I have only one external address and only a few ports forwarded, so I can't >detect portscans. I have noticed that an attempt to guess passwords on SSH is >often, but not always, preceded by a connect and disconnect from the same IP >address, which is probably part of a portscan. I don't block addresses that >scan ports, but I do block addresses that try to guess passwords (not on the >Tor box, just on the other one). The block expires in a day. > To each his/her own. Legitimate port scanning operations are typically run by system/network administrators against the machines on their *own networks*. I treat any others as attackers or at least attacker-wannabes, and I keep track of such miscreants indefinitely against the possibility that I might someday provide services other than tor relaying. The miscreants will have no access to such services on general principles and will only have access to the tor node if and when they are currently running a public (i.e., not a bridge) tor node on the system with the IP address from which their tor attempts to connect to mine. 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 * **********************************************************************

4 4

Bridges on OpenWrt
by Mitar 29 Mar '11

29 Mar '11

Hi! Is there some package for running Tor bridges on OpenWrt supported devices? But as I understand Tor bridges consumes same amount of CPU power and RAM as Tor itself so they are not really possible for low power devices as WiFi routers where OpenWrt normally runes (with typically around 16 MB RAM and 200 MHz CPU power). But on the other hand, as we have in operation a lot of WiFi routers around the country, many of them having their own public IP from very diverse IP ranges, this would be quite useful for bridges. So my question is if somebody has tried to do something like that? Have some experience with it? And also if maybe bridges support would be possible to extend so that we could make (low overhead) tunnels from this WiFi routers to the central server where there would be running a Tor node connected to the Tor network, having enough CPU power and RAM to run everything. So it would be great if the Tor clients would be able to connect to those VPNed end points, but encryption itself would be done on the server. Mitar

3 5

multiple tor nodes on one router? was first using bridge then become bridge
by Lorenz Kirchner 27 Mar '11

27 Mar '11

Hi everyone, so I received no hint as to how or whether to pursue this thought... i shall find other sources of information I just started reading the manual, would you believe it.. I have a new question now, I currently have set up number of tor relays on my router which are loadbalanced using squid... in the hope to increase throughput and perhaps achieve increased anonymity by sending requests for one site through different tor routes... Is that advisable or even effective? My feeling is that the connection is somewhat more reliable than with just one tor relay.. and following on with this could one of these relays be set up to connect to tor via a bridge and then pass directory info on to the other relays running on the same machine? Kind regards, Loz On Thu, Mar 10, 2011 at 11:16 PM, Lorenz Kirchner <znerol2(a)gmail.com> wrote: > On 3/9/11 11:29 PM, mick wrote: > >> >> This this: >>> https://sites.google.com/a/infosecurity.ch/testst/ >>> >>> It's the google spreadsheet that load the bridge information embedded >>> into a google site. >>> >> I need a google account for that. What if I don't want one? >> >> So, any new ideas anybody? I still feel it would be best if 1. there was > a special function within tor to change from using a bridge to becoming a > bridge whithin the censored network, and 2. spreading this bridge-status > info locally... perhaps like dht in torrent.. only revealing a small > selection of available bridges nearby.. i obviously only have a very dim > idea of what i'm talking about.. sorry about that > > anyways, if these two problems could be addressed tor could be a biggie > with a lot of people here.. ;) -- think: cheap openwrt low maintenance > appliance.. > > Loz >

2 2

what updates do I need to install?
by Kathryn Cramer 25 Mar '11

25 Mar '11

I gather from Jacob's Twitter feed that I should download and install the new Tor Browser Bundle because of security updates. Will this affect the relay I am running? Do I also need to update Vidalia? Kathryn

2 1

IRQ affinity
by Mitar 24 Mar '11

24 Mar '11

Hi! I do not know if you have solved this but reading here: http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-li… It is written that: "So if on your system CPU0 handles all interrupts by default, this probably means that APIC configured ambiguously." So maybe it is nothing wrong with e1000e drivers/cards but with APIC configuration? Mitar

1 1

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 21 Mar '11

21 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 16 Mar '11

16 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 09 Mar '11

09 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 09 Mar '11

09 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 09 Mar '11

09 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

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

08 Mar '11

On Fri, 25 Feb 2011 18:28:24 -0500 cmeclax-sazri <cmeclax-sazri(a)ixazon.dynip.com> wrote: >On Friday 25 February 2011 11:45:04 Bianco Veigel wrote: >> 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? > >It may be possible to detect a scan by looking for RST packets coming back >from computers that have the port closed. I saw something about that on >snort.org, I wouldn't trust Snort to do the right thing in the case of >someone portscanning through Tor. I suggest closing the circuit, and only Tor Not only that, but some systems offer the option of not returning the RST packets. For example, on my system (FreeBSD 7.4-STABLE), I have a line in /etc/sysctl.conf, net.inet.tcp.blackhole=2 which takes effect during system startup. Its effect is to cause the kernel to discard and otherwise ignore ALL inbound TCP packets for closed TCP ports. Because the scanner receives no RST, it will likely be delayed until the timeout occurs for the expected ACK/RST that will never arrive. I also have two applicable rules for my packet filter (pf): block drop in log on bge0 proto tcp from any to bge0 flags S/S block drop in log on bge0 proto udp from any to bge0 where bge0 is my Internet-facing network interface. The former drops without returning an RST any SYN that arrives for a closed TCP port. This happens *before* the SYN can encounter the kernel blackhole code, so that I can have a log entry for the attempt. The latter does the same for any unexpected inbound UDP packets. (pf keeps the equivalent of state information for UDP, too, so that UDP responses to requests from my system (e.g., DNS queries) are recognized and allowed in without being subjected to the rule shown above.) I add the addresses logged by the rules above to my file of blocked addresses and address ranges. At present, the only open TCP ports I have are my relay's ORPort and DirPort, so having one's IP address in my "blocked" file can only cause grief to people attempting to connect to/probe my node directly from their tor clients. However, in the event that I might ever offer other services of any kind, all of those creeps will be denied access to those services as well. (N.B. that I have other pf rules that allow IP addresses of relays in the latest cached-consensus file on my node to connect to both of tor's ports. The cached-consensus file is converted every thirty minutes to a "pass" file for just those ports, so no tor user whose client happens to choose a route through a relay in my "block" file will be stopped from building and using a circuit through both the offending node and my node.) My "block" file is currently 10,177 lines long, each line bearing one IP address or address/mask range. >knows what the circuit is, so if an exit node notices several connection >attempts in a row on the same circuit fail, it could close the circuit >because it looks like a portscan. > However, by that time, the target may also have noticed the same series of attempts and will eventually complain to the OP's ISP. :-( Many of the scanning attempts I've seen in my log have involved just a single try on each of a handful of ports. Sometimes they repeat the sequence a few minutes later, a trick that would likely evade the tactic you propose. BTW, something I've noticed moderately frequently in recent weeks is the arrival of unsolicited UDP packets for the UDP port number that matches my (TCP) ORPort number. This usually involves only a single UDP packet so addressed from any given source address. This has me rather mystified regarding what it might be intended to accomplish. If anyone has an idea what it might be about, please let me know. 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

500 TB since last reboot
by Olaf Selke 07 Mar '11

07 Mar '11

anonymizer2:~# ifconfig eth0 | grep bytes RX bytes:556140680407980 (505.8 TiB) TX bytes:575306739180987 (523.2 TiB) anonymizer2:~# uptime 20:14:25 up 123 days, 21:04, 1 user, load average: 1.62, 1.70, 1.60

1 0

Are friends family?
by cmeclax-sazri 03 Mar '11

03 Mar '11

A friend of mine is interested in Tor. If I set up Tor on her box, and I have root access, should I list her relay in my relay's family, or should I list my relay in her relay's family? cmeclax

2 1

Re: [tor-relays] Advice for high throughput Tor node
by Mike Perry 02 Mar '11

02 Mar '11

This discussion is better suited for tor-relays(a)torproject.org. Also, for reference, here is the previous tor-relays thread on the technical aspects of this topic: http://archives.seul.org/or/relays/Aug-2010/msg00034.html And also the social side: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment We really need to work on condensing that tor-relays thread into a single document like the blog post. We've still got a lot of mystery and voodoo to unravel in terms of utilizing all spare Tor capcity, though. Thus spake Mitar (mmitar(a)gmail.com) > Hi! > > We are planning a high throughput Tor node, we are hoping for 1 Gbit/s > node. But as I read there are some issues attaining that. So I would > like some suggestions what should we use for hardware and > configuration to attain it. So CPU, ethernet card, etc. As I > understood it is necessary to run multiple Tor instances, but that > then ethernet card's IRQ affinity is still problematic? Would it be > better to have multiple ethernet cards? How much CPU is needed for 1 > Gbit/s throughput? RAM? > > And it is probably also necessary to have multiple IPs to be able to > have more than 65k connections? > > The problem is that we will probably not be able to experiment much, > what we will buy we will have. So I am hoping to get it right. > > We are targeting a fully open exit node policy so some advice on how > to arrange things with ISP would also be good. We have good experience > with one local ISP, but not on this scale. So probably it would be > good to request a SWIP and abuse handle to our e-mail? Anything else? > Is there any software developed which would handle automatic abuse > e-mails with automatic replies? > > I am sorry if all this is already somewhere written. ;-) > > (And all this is still just in a planning stage, we will have to see > if the budget will support it.) > > > Mitar > _______________________________________________ > tor-talk mailing list > tor-talk(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry Mad Computer Scientist fscked.org evil labs

3 6