- tor-relays - lists.torproject.org

Running exit-node in Germany
by Matthias Redies 02 Aug '13

02 Aug '13

Hello, I want to run an exit-node through mit home connection. Has anyone experience with running a Tor-Relay in Germany( Bavaria)? Are there known cases of police raids? Is there a list of lawyers which work with the torproject which should be called in case of a raid? Has anyone had sucsess with talking to the police prior to setting up the exit-node? If so, to which departmed did you talk to? Yours Matthias

11 18

Home broadband - worth running a relay?
by Nick 01 Aug '13

01 Aug '13

Hi there, I have a reasonable ADSL connection, and a little always-on server. The bandwidth is in the region of 2Mib/s down, something less up (maybe 256Kib/s). Is it useful for me to run a tor relay with this bandwidth? I'd like to run one which isn't an exit, at least for now. If not, am I correct in thinking that a bridge is an appropriate help? That's what I'm doing currently, but if a relay would be more useful I'd be very happy to do that. One other unrelated(ish) question: I'm in the UK, where the idea of censorship isn't resisted as strongly as it ought to be, and as a result my internet connection is subject to a smallish amount of censorship: whatever is on the secret IWF blacklist plus the pirate bay. Does this mean that running an exit node from a home connection here at some point in the future would not be helpful? Or only if all HTTP(S) was blocked (as the IWF blacklist is secret there's presumably no way to tell the tor network what is inaccessible from this node). Thanks in advance, Nick

12 23

Diagnosing "relay unresponsive" messages
by Gordon Morehouse 01 Aug '13

01 Aug '13

So, I've got my relay back up on a Raspberry Pi and I'm working on figuring out the optimizations I made to it, and continuing to tune it. Out of the box these machines have some difficulty even offering a couple Mbps, but they can be greatly improved. I will post all details when done. I see a fair amount of this, much less than after some tweaks, but it still happens: 20:27:36 [ARM_NOTICE] Relay resumed [1 duplicate hidden] 20:27:30 [ARM_NOTICE] Relay unresponsive (last heartbeat: Wed Jul 31 20:27:19 2013) 19:50:57 [ARM_NOTICE] Relay unresponsive (last heartbeat: Wed Jul 31 19:50:4 This often happens at the same time as 'arm' (the monitoring program) may stutter, fail to render a few frames, then 'catch up' or redraw the screen. I'm trying to figure out what's going on so I can prevent it. It doesn't always correlate with traffic - it happens more often when there's more traffic but can happen even with very little. Tor is taking about 10% RAM, there's plenty free, and load is under 1.0. Best, -Gordon M.

1 0

What to do about port scans?
by Steve Snyder 31 Jul '13

31 Jul '13

I wouldn't have thought that the Tor network was fast enough for port scanning, but apparently it is. I have recently seen a rash of SSH port scanning (or so my ISP reports). What can/should I do about this? I know I can limit the rate of connections using iptables. What's the consensus on this? Is this considered advisable, or a breach of expected exit node behavior? Do I have any options other than iptables to restrict the rate of port 22 connection attempts? Thanks.

3 3

Re: [tor-relays] Home broadband - worth running a relay?
by ROCKsolid69r＠gmail.com 31 Jul '13

31 Jul '13

1 0

Re: [tor-relays] Home broadband - worth running a relay?
by ROCKsolid69r＠gmail.com 31 Jul '13

31 Jul '13

1 0

VPN termination on relays
by grarpamp 31 Jul '13

31 Jul '13

> Mosh is great, but it still relies exclusively on UDP, right? > So no "over Tor"... Somewhat related to things that don't work via exits... So who wants to offer VPN termination as part of their exit service? User tunnels VPN to you, you give back a bound port, or a natted 10 address, somethings of that sort.

1 0

Fwd: Computer requirements for a modest (15-20Mbs) relay?
by Zack Weinberg 31 Jul '13

31 Jul '13

On Mon, Jul 29, 2013 at 12:35 PM, Andy Isaacson <adi(a)hexapodia.org> wrote: > Yes, there are cases of law enforcement seizing all computer gear from a > house with a exit node -- not just the exit node computer. Most > recently in Austria in a child porn investigation. [...] We did some operational planning for this risk, in conjunction with the university legal and IT departments, when we set up the CMU Tor exit. The machine is in a cube farm filled with other equipment that people need for their work; this is because we want to have immediate physical access to it in an emergency, and anywhere else we could put it would interfere with that. However, it has its own dedicated IP address, it runs absolutely no other services, it is clearly labeled both in DNS and on the physical box, and there's nothing else on the table it sits on. The hope is that this will be sufficient to persuade law enforcement to seize *only* that machine, if it comes to it. Of course, it helps as much or more to have the equipment under the aegis of an organization with lawyers already briefed and on tap, and that has trained all the staff to call legal *before doing anything else* when the police show up. Also, the greater operational threat is having the plug pulled by one's connectivity provider. I personally would not risk having an exit node in my house for that reason alone. zw

3 3

Sitevalley is no longer Tor-friendly
by Tom Ritter 30 Jul '13

30 Jul '13

Sending this out, as I suspect I am not the only person running a node on SiteValley, as they have pretty good bandwidth for pretty cheap. I had inquired in the beginning if they allowed Tor, and they said yes, but if we get too many abuse complaints we'll shut it down. So maybe 4 or 5 abuse complaints later they did indeed give me the ultimatum to shut it down or get shut down. So I made them give me a new IP address, and made it into a middle node. (The new IP was because I was thinking of making it a bridge.) Well this morning they told me TOR (their caps, not mine ;) is not allowed at all. I argued with them a little bit, and TLDR you might be able to get a partial refund. I'd much rather have had the bandwidth though. I'm not in a position to run high-maintence nodes, so this being a pretty fast, maintenance-once-every-three-months dedicated-to-Tor node - I was pretty happy with it. Our conversation: ----------------- Your VPS X.Y.Z.W has been suspended due to running tor anonymyzer which is forbidden according to our Acceptable Use Policy, paragraph 8 "Prohibited Activities" http://www.sitevalley.com/acceptable-use-policy/. In order to have your VPS unsuspended you need to agree to remove tor from it within 24 hours after the unsuspension. Failure to abide by this provision may result in termination of your account. We have to warn you that on receiving next abuse your VPS will be terminated without without prior notice. ----------------- If you refer to Contact Form ID #YXX-XXXXyou'll see that I confirmed with you before I purchased the VPS that allowing Tor was acceptable. I dealt with the 3 or 4 abuse complaints you sent me promptly, and in #FSA-XXXXI agreed to stop using the server as a Tor Exit Node, despite our previous conversation. The machine in question is running Tor in a non-Exit mode. Traffic from it does not appear to originate from the server, and it merely passes traffic within the Tor network. It cannot generate abuse complaints from third parties when running in this mode. Have you received an abuse complaint about this server? If so, can you forward it to me so I can investigate how it may have been created? ----------------- The node was found during system audit. May be you know that running tor (in any mode) is strictly forbidden by our Acceptable Use Policy because it can be used by third-parties for forwarding hidden illegal traffic. Unfortunately, we can start your VPS only in case you agree to remove tor. ----------------- I'll put aside the fact that your routers, DNS resolvers and every router of the internet also carries hidden illegal traffic, and that Tor is agnostic to that traffic as your routers are. I did NOT know that running Tor was not allowed because I ASKED you if I could, and you told me it was fine as long as it did not generate Abuse Complaints. Considering your AUP is so broad it can be made to cover anything you don't like, the only reasonable thing someone can do is ask if you'll allow something - which I did. I'd like a pro-rated refund of my remaining service, as you have misrepresented your services and your Acceptable Use Policy to me - if I had known you wouldn't allow me to use my bandwidth in a way that was not illegal in any jurisdiction, did not generate any abuse complaints or additional work for you, and that you would shut down my service after I confirmed what I was doing was okay with you - I would never have paid you in the first place. ----------------- Ticket YXX-XXXX dates from 26 Mar 2012. Our Terms of Service are subject to change and, according to our Terms of Service http://www.sitevalley.com/terms/ posting of such changed Terms and Conditions on the site constitutes notice of such changes to you (although we may choose additional types of notice). Our policy regarding TOR usage has been changed and as for now, running TOR applications on our servers is forbidden. We are very sorry that this provision prevents you from using our services in the manner you need to use it. All things considered, we can offer you two options: 1. We unsuspend your VPS, you remove TOR from it, let us know and we check it. or 2. We issue the partial refund and terminate your account with us. Please rest assured that we value you as our customer and would like to continue doing business with you. Also, please accept our apologies for any inconvenience this misunderstanding has been the reason of. ----------------- Thank you Dmitriy. Please issue the partial refund and terminate the account. ----------------- -tom

13 21

Computer requirements for a modest (15-20Mbs) relay?
by Nick 29 Jul '13

29 Jul '13

Hi, I'm probably going to move to a new ISP soon, and may well be able to get a fibre 20Mbps up connection, which is a nice thought. The question I have is whether my little ~1GHz home server box (a weird little x86 thing, I can dig out more specs if they're relevant) would be able to relay that level of traffic without issue? The TorExitGuidelines page on the wiki mentions that one "modern" CPU core should be able to push 100Mbps, but my server is probably 6/7 years old. It's a VIA board, which IIRC might have some hardware crypto acceleration or something - is that something that would be likely to help things if I can get it working? Thanks folks, Nick P.S. Are there any known cases of law enforcement seizing equipment or otherwise terrorising people for running home exit nodes? I would like to imagine that Tor is well known enough in such circles that such action would be rather unlikely nowadays. I know at least some remailer operators host stuff from their homes, but maybe that's lower risk.

2 1

Tor exit node flags explanation
by Bernard Tyers - ei8fdb 26 Jul '13

26 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have looked thru FAQs and docs but can't find an answer (no doubt its in front of me somewhere). Is there any explanation of what Tor node flags mean? Specifically the "Named" flag. It has recently been applied to my node. thanks, Bernard - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR8nm1AAoJENsz1IO7MIrrxjQIAIRB/Y+a0fyQvcA/b/3+PuT8 spVgrS6Ts39w0xncwO1DCcCDzA1EmEaQy2I6VZ1YYIk+qrDXSkyP8Gl2ACWJ8SZi Wjmt9OeQZYE3thUfXlEX4K0iqiu1vc26dHxR0VAwqV9a4GAFJ6vmDiwNLqhjEjVA a/uQdNwx1kPfApHMIDRRmBFRWGJ5v//3XxN1nS7Ty5q2ngR7ws9xfRJ6awpRrYFN vRpHPG/BGQGbcCsBsecGu/nSJaN+2mfqb9fRaHIeDUBtn6xV465BxmhZwCzf2sL4 jYoMnLByJodfImhT53qPBlgs/7HNuMbFldeREI21QlWEVi4eaN9BLS2/fe+rLQA= =R/y8 -----END PGP SIGNATURE-----

2 1

Yet another underpowered relay?
by Logforme 23 Jul '13

23 Jul '13

I recently upgraded from an adsl line to a 100mbit fiber connection. Naturally I want to use most of this new bandwidth for my non-exit tor relay. However, I run into messages like these: Jul 22 17:40:26.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [665 similar message(s) suppressed in last 60 seconds] Jul 22 17:40:26.000 [warn] Failed to hand off onionskin. Closing. [1509 similar message(s) suppressed in last 21600 seconds] Relay fingerprint: BE71 DC9D A443 5855 FAE1 E369 7080 1A60 0D51 3684 Relevant torrc settings: BandwidthRate 10 MB BandwidthBurst 10 MB NumCPUs 2 I did some research and came up with the following things to try: Set "MaxAdvertisedBandwidth x MB" Set "MaxOnionsPending 250" Get a faster computer / Get a computer with AES-NI I tried setting "MaxAdvertisedBandwidth 9 MB" for a few days which didn't seem to do much difference. This is only a 1MB reduction from the 10MB i use as a hard limit. Too little? Must I wait longer for the change to get spread around? Setting "MaxOnionsPending 250" seem to have reduced the number of log messages, but not eliminated them. The computer is somewhat dated but not ancient: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz, 4 cores with HT, 6GB mem. I feel it should be able to handle a 80 mbit bandwidth but have no hard data to support this. Looking at htop tor uses 2 cores. One core is constantly at around 90% (when all the 80 mbit bandwidth is used). The second core is hardly used. Since the relay can handle 80mbit (and higher) without messages I assume the problems only occur when the number of circuits get very high. Questions: What value should I set for MaxAdvertisedBandwidth? What other torrc settings could improve the situation? Am I wrong in thinking my cpu should be able to handle 80 mbit? Would upgrading to 0.2.4.15-rc-1 help? Weird sidenote: If I start iftop the first core drops to around 40-50%. Stop iftop and it jumps back to 90%. No change in traffic. What could that mean?

4 4

Re: [tor-relays] Exit relay operators: a call for packets on port 8118
by rotpoison throngnet 22 Jul '13

22 Jul '13

I believe you are exactly right, Javntea. Thank you for the insight. I opened up Privoxy for a few seconds on my node (below) and had similar results. I had no idea that pay for click advertisers would even accept referrals from Tor. It is pretty basic to filter identified exit relays and other anonymous proxies. So apparently the return of investment from this sort of clickfraud pays the leasing bills of thousands of servers? WoW, I have been schooled... - Kent 09:21:01.419951 IP 23.19.89.126.2318 > my.exit.node.8118: Flags [P.], seq 1:416, ack 1, win 65535, length 415 E.....@.u.u/..Y~B... ...^.]^M....P.......GET http://ad.media-servers.net/st?ad_type=iframe&ad_size=160x600&section=44321… Accept: */* Referer: http://giftcardsrus.net/index.php?option=com_content&view=article&id=1741:w… Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) Host: ad.media-servers.net Connection: Keep-Alive 09:21:01.419973 IP my.exit.node.8118 > 23.19.89.126.2318: Flags [.], ack 416, win 6432, length 0 E..(..@.@...B.....Y~.. .....^.^.P.. .k.. 09:21:01.420501 IP my.exit.node.8118 > 23.19.89.126.2318: Flags [P.], seq 1:256, ack 416, win 6432, length 255 E..'..@.@...B.....Y~.. .....^.^.P.. .j..HTTP/1.0 403 Request blocked by Privoxy Content-Type: image/png Content-Length: 102 Cache-Control: no-cache Date: Mon, 22 Jul 2013 09:21:01 GMT Last-Modified: Wed, 08 Jun 1955 12:00:00 GMT Expires: Sat, 17 Jun 2000 12:00:00 GMT Pragma: no-cache 09:21:01.430712 IP 173.208.16.93.1094 > my.exit.node.8118: Flags [.], ack 1, win 65535, length 0 E..(...........]B....F...._..x..P....~........ 09:21:01.431701 IP 173.208.16.93.1094 > my.exit.node.8118: Flags [P.], seq 1:511, ack 1, win 65535, length 510 E..&...........]B....F...._..x..P.......GET http://ad.globe7.com/st?ad_type=pop&ad_size=0x0&section=3910946&banned_pop_… Accept: */* Referer: http://twicemagic.com/index.php?option=com_content&view=category&layout=blo… Accept-Language: en-us User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; Media Center PC 6.0; InfoPath.3; MS-RTC LM 8; Zune 4.7) Host: ad.globe7.com Connection: Keep-Alive 09:21:01.431722 IP my.exit.node.8118 > 173.208.16.93.1094: Flags [.], ack 511, win 6432, length 0 E..(..@.@.b.B......]...F.x....a.P.. .... 09:21:01.432462 IP my.exit.node.8118 > 173.208.16.93.1094: Flags [P.], seq 1:256, ack 511, win 6432, length 255 E..'..@.@.a.B......]...F.x....a.P.. ....HTTP/1.0 403 Request blocked by Privoxy Content-Type: image/png Content-Length: 102 Cache-Control: no-cache Message: 3 Date: Mon, 22 Jul 2013 00:09:55 -0700 (PDT) From: Javantea <jvoss(a)altsci.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Exit relay operators: a call for packets on port 8118 Message-ID: <20130722070955.1CF571380F1(a)mail.altsci.com> Content-Type: text/plain; charset="us-ascii" Hi Kent, I am getting 125 packets per second sustained incoming on port 8118 like you on my exit node. I noticed this last year but forgot about it because it was such low bandwidth. I count 2582 unique IPs in 20 minutes. I think you've found something significant. The obvious question is why since sending data in the clear is pretty worthless and it's going to come out of a tor exit node just like if they were using tor. I'm a security researcher and would be happy to help you learn more about these silly systems. You've already done most of the basic research though: who, what, and where. When I open port 8118 with netcat a few times I get this: GET http://ad.yieldmanager.com/st?ad_type=iframe&ad_size=300x250&section=421110… HTTP/1.0 Accept: */* Referer: http://www.lotsoffree.com/index.php?option=com_content&view=article&id=84:f… Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Host: ad.yieldmanager.com Connection: Keep-Alive GET http://ib.adnxs.com/ttj?id=1284883 HTTP/1.0 Accept: */* Referer: http://www.psxobs.com/privacy-policy Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Host: ib.adnxs.com Connection: Keep-Alive That looks like clickfraud to me. Perhaps someone wrote a quick script that downloads the list of tor exit nodes and sends clickfraud requests to 8118 and was too lazy to add tor. That would mean that the sites in the referrer are the attackers and the url on the first line is the ad service which is being defrauded. Of course there is the possibility of a joe job occuring, but we know that at least some of them are the bad actors. Whois on both referrers returns China. I'm surprised that the script doesn't remove servers from the list that have the port closed. It's a very inefficient script. Regards, Javantea

1 0

relay uptime
by l3thal 22 Jul '13

22 Jul '13

Hi, I recently edited my torrc and accidentally did restart instead of reload so my uptime was reset. Will this negatively impact the 60 days to get a tshirt? -- l3thal - SmashTheStack <http://smashthestack.org>

2 2

Checking my Tor bridge and adventage of dynamic ip addresses
by nobleeightfoldpath＠lavabit.com 20 Jul '13

20 Jul '13

Hi list members, Iam kinda new to Tor and decided to run a relay and found heavy traffic on my router. No prob, but after reading the documentation and some discussion boards I decided to make internet access possible for people living in censorship and run a bridge on Linux without Vidalia and other x related apps. I use "Arm" to check the Tor daemon activities. The bridge runs a few days and I see: flags: no, and there is nearly zero traffic, avg 1.4 Kbs, mostly 0. Arm displays connections and I see some IP addresses, 2 circuits. And often just - nothing. Obviously Tor is running, but Iam afraid that my config isn't useful... How can I check my bridge is really working? Another question comes up. I use a cable connection to my ISP and they don't change my IP address, until plugging off my modem and wait an hour... I think if my bridge IP address is some day on some black lists, it could be an adventage if my IP address changes, right? If so, what changing time is fine, every day? Regards

5 8

Bandwidth Spike
by Bryan Carey 19 Jul '13

19 Jul '13

I'm a fairly new Tor relay operator and noticed something peculiar with my bandwidth for the relay recently. It seems to have jumped WAY up and just plateaued at what I have the peak bandwidth limit set at. Is there any kind of explanation for this? Is this normal behavior? Could it indicate some kind of denial of service attack? Here's a screenshot I took of the bandwidth history: https://i.imgur.com/mRyKp9L.jpg (note that both R/W plateau at the same point in time) Perhaps this is normal behavior but I want to know if it's something that might be messed up with my configuration that I can correct. -Bryan

2 1

hardware
by Andreas Fink 15 Jul '13

15 Jul '13

can someone give me hints on what hardware would be best suited to run big fat tor exit nodes connected with multiple 1gbps or 10gps links? We are considering putting some fat boxes near major internet exchanges of the world. sent from iPhone

5 6

TCP: Peer unexpectedly shrunk window
by krishna e bera 15 Jul '13

15 Jul '13

Are such messages something to worry about? What do they mean? Example from dmesg log: [422949.356062] TCP: Peer 79.22.114.39:60467/9001 unexpectedly shrunk window 2565384113:2565389251 (repaired) [427073.032013] TCP: Peer 217.20.253.198:17482/9001 unexpectedly shrunk window 2017146666:2017147597 (repaired) [478256.668534] TCP: Peer 2.236.7.28:49367/9001 unexpectedly shrunk window 176191274:176194194 (repaired) [502615.724129] TCP: Peer 217.20.253.198:53308/9001 unexpectedly shrunk window 792267503:792268436 (repaired) [514591.656053] TCP: Peer 217.20.253.198:63743/9001 unexpectedly shrunk window 445257517:445258452 (repaired) [527753.064036] TCP: Peer 94.38.5.188:49377/9001 unexpectedly shrunk window 2291195973:2291197433 (repaired) [633078.304041] TCP: Peer 87.89.75.107:59567/9001 unexpectedly shrunk window 3718547610:3718553466 (repaired) [633079.672021] TCP: Peer 87.89.75.107:59567/9001 unexpectedly shrunk window 3718547610:3718553466 (repaired) [673170.600037] TCP: Peer 82.89.173.120:50392/9001 unexpectedly shrunk window 2473022599:2473024051 (repaired) [714540.672036] TCP: Peer 217.20.253.198:20805/9001 unexpectedly shrunk window 3814426018:3814426947 (repaired) [755391.792076] TCP: Peer 79.223.168.103:61238/9001 unexpectedly shrunk window 2799388466:2799406672 (repaired) [755392.864013] TCP: Peer 79.223.168.103:61238/9001 unexpectedly shrunk window 2799388466:2799406672 (repaired)

3 2

Why doesn't my Tor Relay (non-exit) show an Onion Key
by gongeek＠gmail.com 15 Jul '13

15 Jul '13

When i check my running tor relay (Fingerprint: $66a81cecd3aef6999982c5abee1942e3e5ab3b1c ) on this site<https://torstatus.blutmagie.de/router_detail.php?FP=66a81cecd3aef6999982c5a…>i notice that the "Onion Key" field (located near bottom of the page) is empty. My relay has been running for over 24 hours and i still dont see anything in that field. I tested out my relay as an EntryNode and i was able to access the internet through tor fine. I have watched the Bandwidth Graph and seen other users use my Relay so it is running fine. But i cant understand why my Onion Key field is empty. When i check other relays on the site (every relay i've checked) has an Onion Key displayed including relays that have just started running less than 10 mins ago. You can see all the relays here <https://torstatus.blutmagie.de/>. Click any and of the displayed relays and notice each has a displayed Onion Key -- except my relay. Any info on why this is would be great Thanks

2 1

Final Warning Notice
by Chris Sheats 11 Jul '13

11 Jul '13

Hey tor-relays, The past few months, since I upgraded my net connection to 1Gbps, I've hit the top 40 fastest relays and the top 20 fastest exit nodes, peaking to over 17 MB/s. I've always prided the fact that my ISP, CondoInternet in Seattle, has been very welcoming of my reduced exit node. In the past, the malicious activity hasn't been "too much" for my ISP--examples here: http://yawnbox.com/1461--but now they want me to shut it down. What are my options? Forwarded email: Final Warning Notice - IP address 216.243.58.198 I am writing you regarding the repeated abuse complaints that we're receiving for your IP allocation. While we at CondoInternet are all for an open and unmolested with Internet experience for our customers as it was one of our founders' primary reasons for starting CondoInternet, your Tor node has generated a disproportional amount of abuse and legal complaints compared to the rest of our customers. We are asking that you remove the Tor node from your CondoInternet connection or to please switch to an alternative service provider by July 15th 2013. We very much appreciate you being part of the CondoInternet family and do apologize for any inconvenience this change may cause you. Please feel free to contact me directly if you have any questions. Sincerely, Operations Manager CondoInternet -- Chris Sheats yawnbox(a)gmail.com

7 9

How does CERT-FI know my SOCKS4 port?
by Steve Snyder 10 Jul '13

10 Jul '13

My ISP recently sent to me a CERT-FI auto-report on malware-infected servers in my ISP's address space. I was send this report because my IP address was among those flagged. My entry looks like this: 51765|aa.bbb.ccc.dd|2013-07-08 02:39:23 +0000|||Proxy|743230|Datasource: C, Type: SOCKS4 (9050) I am wondering how CERT-FI knows about this port. This is a snippet of my relay config: OutboundBindAddress aa.bbb.ccc.dd ORPort [aa.bbb.ccc.dd]:443 DirPort [aa.bbb.ccc.dd]:80 SocksPort [127.0.0.1]:9050 Given that my SOCKS port is bound to localhost, how does CERT-FI know about it? (For more info on the auto-reporter, go to https://www.cert.fi/en/autoreporter/autoreporter.html and log into it with this username/password: auto/reporter) Thanks.

3 2

Unbalanced send/recieve
by Christian 10 Jul '13

10 Jul '13

Hi all, sorry for my probable newbie question. My bridge's log file reads: Jul 10 11:21:34.000 [notice] Heartbeat: Tor's uptime is 17:52 hours, with 4 circuits open. I've sent 12.55 MB and received 209.33 MB. Is it normal to have such an unbalanced ratio or do I have to worry about something? In the past, I always used to recieve a quart more than I sent which I couldn't quite explain, but now... Thanks for an answer. Sincerly christian

3 2

Circuit creation "storms" overwhelming > Raspberry Pi?
by temp5＠tormail.org 09 Jul '13

09 Jul '13

FWIW, I did some tuning on mine (not a pi, but had similar issues) and it seems more stable now too. I added the following to my torrc (where X and Y are your rates/units): MaxOnionsPending 250 BandwidthRate X BandwidthBurst Y RelayBandwidthRate X RelayBandwidthBurst Y I had the RelayBandwidth options already in it, but I read somewhere the added Bandwidth options above should limit directory port traffic bursts. And MaxOnionsPending allows more to queue up before creating errors. It sounds like the next major version of Tor (in release candidate stage right now) has several performance improvements, so you might just want to wait for that to release and see if the problems disappear on their own thanks to the hard work of the developers! > From: Gordon Morehouse <gordon(a)morehouse.me> > > Hi, Yes. This is absolutely on my to-do list. I've had a family > medical emergency and about 2 or 3 other things recently about that > level of stress, but BELIEVE me, a strategy for getting a Raspberry Pi > to be a rock solid relay is of paramount importance to me. > > I'm hoping to figure out all the tweaks I did, and then make an alpha > version of some iptables rules to defend against the "storms," within > the next couple of weeks. > > Please don't hesitate to bug me about this at my direct email. (The old > one is no longer valid, I've dropped pseudonyms on the tor lists.) > > Thanks much, > -Gordon M. > > > Thomas Hand: >> Hi torsion, >> >> I'm also running a tor relay on a raspberry pi and keep getting these >> storm >> creation events which crash the box. You said you made some adjustments >> to >> the configs to get a more stable system? Can you please email me copies >> of >> the configs or maybe list the changes you made? >> I'm trying to get my pi stable and then perhaps role out a few more >> relay >> nodes to friends and colleagues. >> Thanks, >> >> T >> >> >> On 4 May 2013 22:07, <torsion(a)ftml.net> wrote: >> >>> I did a lot of tuning on the Raspberry Pi and it's now much, much more >>> stable as a Tor relay, but just now I had another "circuit creation >>> storm." Interestingly, the Pi remained up, and my *router* crashed. >>> I've also seen huge bursts of circuit creation on a relay I run on a >>> VPS, but as it's a much more powerful box it rarely complains (and thus >>> I rarely notice). >>> >>> This many circuits and outbound connections is highly unusual for the >>> small relay I'm running on the Pi. And this behavior definitely occurs >>> in bursts. Is this an outbound DDOS or an attack on Tor itself? If >>> the >>> former (or maybe the latter), is there some way I could perhaps use >>> iptables to temporarily "clamp" the ability to open TCP connections >>> when >>> Tor (or anything on the Pi) opens a number over some threshold in some >>> short period of time? >>> >>> Here's log output (via 'arm') from the relay after my router crashed >>> twice, I went to the admin panel and noted hundreds of outbound >>> connections from my Tor box. Time is America/Los_Angeles. >>> >>> ? 13:55:00 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat May 4 >>> 13:54:14 2013) >>> ? 13:52:25 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [404 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:51:07 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [75 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:50:52 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [601 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:48:39 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [99 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:47:34 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [22 similar message(s) suppressed >>> in >>> last 60 seconds] >>> ? 13:46:17 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [253 similar message(s) suppressed >>> in last 60 seconds] >>> ? 13:43:47 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [1396 similar message(s) suppressed >>> in last 60 >>> ? seconds] >>> ? 13:42:48 [WARN] Your computer is too slow to handle this many >>> circuit >>> creation >>> ? requests! Please consider using the MaxAdvertisedBandwidth config >>> option or choosing >>> ? a more restricted exit policy. [16 similar message(s) suppressed >>> in >>> last 60 seconds] >>> >>> Here's how it crashed my router (blowing ip_conntrack limits is >>> sufficient only to mess up many of my TCP connections, but eventually >>> the router runs out of memory and starts killing processes): >>> >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:25 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:29 dedmaus user.warn kernel: NET: 152 messages suppressed. >>> May 4 13:51:29 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:34 dedmaus user.warn kernel: NET: 193 messages suppressed. >>> May 4 13:51:34 dedmaus user.warn kernel: ip_conntrack: table full, >>> dropping packet. >>> May 4 13:51:39 dedmaus user.warn kernel: NET: 227 messages suppressed. >>> >>> ...ad infinitum with the number of messages suppressed per 5 sec >>> increasing until the router crashes. >>> >>> >>> >>> On Mon, Mar 18, 2013, at 06:18 PM, torsion(a)ftml.net wrote: >>>> I'm also seeing occasional messages like this on the Pi (it never >>>> lasts >>>> long): >>>> >>>> 18:13:24 [ARM_NOTICE] Relay resumed >>>> 18:13:18 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 18:13:04 2013) >>>> 17:28:43 [ARM_NOTICE] Relay resumed >>>> 17:28:38 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 17:28:25 2013) >>>> 14:12:26 [ARM_NOTICE] Relay resumed >>>> 14:12:20 [ARM_WARN] Deduplication took too long. Its current >>>> implementation has difficulty handling large logs so disabling it to >>>> keep the interface responsive. >>>> 14:12:20 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18 >>>> 14:12:06 20 >>>> >>>> On Mon, Mar 18, 2013, at 01:00 PM, torsion(a)ftml.net wrote: >>>>> Hi there, I just joined the mailing list and apologized if this has >>> been >>>>> discussed before. I did find discussion of a similar issue in >>>>> January >>>>> 2013's archive: >>>>> >>>>> >>> https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html >>>>> >>>>> It's important to note that I believe I've seen (but didn't save >>>>> logs) >>> a >>>>> couple "circuit creation burst" events on my established relay (about >>>>> 5Mbps, stable, guard, non-exit) which was mostly able to handle it >>>>> without crashing as it has plenty of RAM and the above-mentioned >>>>> messages - "Your computer is too slow to handle this many circuit >>>>> creation requests! Please consider using the MaxAdvertisedBandwidth >>>>> config option or choosing a m ore restricted exit policy." - appear >>> only >>>>> with the relay is under load for other reasons AND a large number of >>>>> circuits are being suddenly created. >>>>> >>>>> I wondered if this was some kind of DOS attempt but didn't think much >>> of >>>>> it because my fast relay continued working fine. >>>>> >>>>> However, I've just set up a Raspberry Pi, the 512MB model, as a relay >>> on >>>>> a slower connection. Here are the relevant settings on this relay: >>>>> >>>>> RelayBandwidthRate 130 KB >>>>> RelayBandwidthBurst 340 KB >>>>> >>>>> The Pi has a fairly slow CPU, so I'd occasionally get messages about >>> log >>>>> deduplication being too slow or something, but didn't think much of >>>>> it. >>>>> I finally got the relay up and left it up for over 24 hours. When I >>>>> woke up this morning it had crashed. Here are the relevant log >>> messages >>>>> - note the huge jump in number of circuits between 22:35 and 04:35 >>>>> (maybe I got the Stable flag), then the storm of circuit open >>>>> requests >>>>> starting at 05:49. Eventually I believe the Pi ran out of memory and >>>>> killed the tor process. >>>>> >>>>> What's very interesting here is that my fast VPS relay with a >>>>> RelayBandwidthRate over 5x faster is almost never handling much more >>>>> than 1000 circuits, so why all of a sudden the demand on the Pi >>>>> that's >>>>> advertising a lower bandwidth rate? >>>>> >>>>> Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 >>>>> hours, with 26 circuits open. I've sent 974.13 MB and received 969.92 >>>>> MB. >>>>> Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00 >>>>> hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 >>>>> GB. >>>>> Mar 18 05:49:44.000 [warn] Your computer is too slow to handle this >>> many >>>>> circuit creation requests! Please consider using the >>>>> MaxAdvertisedBandwidth config option or choosing a more restricted >>>>> exit >>>>> policy. >>>>> Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing. >>>>> Mar 18 05:50:44.000 [warn] Your computer is too slow to handle this >>> many >>>>> circuit creation requests! Please consider using the >>>>> MaxAdvertisedBandwidth config option or choosing a more restricted >>>>> exit >>>>> policy. [5817 similar message(s) suppressed in last 60 seconds] >>>>> Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds >>>>> forward; assuming established circuits no longer work. >>>>> Mar 18 05:53:51.000 [warn] Your computer is too slow to handle this >>> many >>>>> circuit creation requests! Please consider using the >>>>> MaxAdvertisedBandwidth config option or choosing a more restricted >>>>> exit >>>>> policy. [1055 similar message(s) suppressed in last 60 seconds] >>>>> Mar 18 05:55:14.000 [warn] Your computer is too slow to handle this >>> many >>>>> circuit creation requests! Please consider using the >>>>> MaxAdvertisedBandwidth config option or choosing a more restricted >>>>> exit >>>>> policy. [329 similar message(s) suppressed in last 60 seconds] >>>>> >>>>> I'd like to figure out just how much the Raspberry Pi is capable of, >>>>> because it could be a cheap way to build out the relay network by >>> people >>>>> who want to donate bandwidth - but of course it needs to be stable, >>>>> and >>>>> something about my setup is not. >>>>> >>>>> Also: >>>>> >>>>> Mar 16 20:55:33.000 [notice] No AES engine found; using AES_* >>> functions. >>>>> >>>>> I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the >>>>> Pi >>>>> has any AES capability, but it'd be great to find out. >>>>> >>>>> _______________________________________________ >>>>> tor-relays mailing list >>>>> tor-relays(a)lists.torproject.org >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > >

1 0

Relay identity
by Jochen 08 Jul '13

08 Jul '13

Hello, I want to create a Raspberry PI image with preinstalled TOR relay for some friends. I will also include a config script to customize torrc (Nickname etc.). I also need to generate a new identity key in this script, so that every node is unique. But I don't know how to generate a new identity. Is there a command to do that, or must I remove /var/lib/*tor*/keys/?

2 1

Circuit creation "storms" overwhelming Raspberry Pi?
by torsion＠ftml.net 08 Jul '13

08 Jul '13

Hi there, I just joined the mailing list and apologized if this has been discussed before. I did find discussion of a similar issue in January 2013's archive: https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html It's important to note that I believe I've seen (but didn't save logs) a couple "circuit creation burst" events on my established relay (about 5Mbps, stable, guard, non-exit) which was mostly able to handle it without crashing as it has plenty of RAM and the above-mentioned messages - "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a m ore restricted exit policy." - appear only with the relay is under load for other reasons AND a large number of circuits are being suddenly created. I wondered if this was some kind of DOS attempt but didn't think much of it because my fast relay continued working fine. However, I've just set up a Raspberry Pi, the 512MB model, as a relay on a slower connection. Here are the relevant settings on this relay: RelayBandwidthRate 130 KB RelayBandwidthBurst 340 KB The Pi has a fairly slow CPU, so I'd occasionally get messages about log deduplication being too slow or something, but didn't think much of it. I finally got the relay up and left it up for over 24 hours. When I woke up this morning it had crashed. Here are the relevant log messages - note the huge jump in number of circuits between 22:35 and 04:35 (maybe I got the Stable flag), then the storm of circuit open requests starting at 05:49. Eventually I believe the Pi ran out of memory and killed the tor process. What's very interesting here is that my fast VPS relay with a RelayBandwidthRate over 5x faster is almost never handling much more than 1000 circuits, so why all of a sudden the demand on the Pi that's advertising a lower bandwidth rate? Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 hours, with 26 circuits open. I've sent 974.13 MB and received 969.92 MB. Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00 hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 GB. Mar 18 05:49:44.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing. Mar 18 05:50:44.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [5817 similar message(s) suppressed in last 60 seconds] Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds forward; assuming established circuits no longer work. Mar 18 05:53:51.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [1055 similar message(s) suppressed in last 60 seconds] Mar 18 05:55:14.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [329 similar message(s) suppressed in last 60 seconds] I'd like to figure out just how much the Raspberry Pi is capable of, because it could be a cheap way to build out the relay network by people who want to donate bandwidth - but of course it needs to be stable, and something about my setup is not. Also: Mar 16 20:55:33.000 [notice] No AES engine found; using AES_* functions. I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the Pi has any AES capability, but it'd be great to find out.

3 4