Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 2014-11-18 16:09, Libertas wrote: [..] https://github.com/plsql/ssh-auth-methods The purpose of this is to alert relay operators that are still allowing password authentication. 2,051 relays offered password auth, and many more likely offer similarly insecure methods or were missed for reasons discussed below. Excellent run! And thanks for bringing this up on this list. Now to hope that folks actually fix their setups though. [..] * SSH being served on a non-standard port - something other than port 22. This is a good idea, as many brute-force attackers will only bother trying port 22. The script I wrote could have used an alternate port number supplied from nmap, but this would run much slower and would potentially get my VPS blocked before it could even get the SSH information. Try 2022, it is a general alternative. People should realize though that it is not 'safer' in any way running SSH on another port. SSH readily shows itself as being SSH and nmap and other tools easily recognize it on other ports. * The server only allowing SSH connections from certain IP addresses. This is also commonly recommended, although it can be a little rigid if you don't have a VPN with a static IP (what if your server goes down while you're away from home?). Actually it is not 'a little rigid' it is the best thing to do: Only allow certain prefixes access If you do not have a static IP address, at minimum limit access to the prefix of your ISP (whois your own IP address and check the 'route' object); though be warned you might change outside that block too. Possibly better, set up IPv6 at home and on the server by getting a free IPv6 tunnel (effectively just also a VPN) from many places around the world (see Wikipedia IPv6 Tunnel Broker List). Then just allow access over the static IPv6 address you have. As there are no SSH scanners on IPv6 you could even opt to not having a filter if you don't publish the address of the endpoint anywhere. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 2014-11-18 18:38, Kevin de Bie wrote: Fail2Ban works really well. Shifting to a non standard port only stops the scriptkids from having too much automated options and does not do anything for actual security. For this reason I personally never bothered with that. Non standard username and password auth with fail2ban makes brute forcing practically impossible, this is usually how I have things configured. Just changing it to key-based authentication stops ALL password-guessing attacks. You will then be left with the logs though. Hence lets make a little list for clarity in order of should at least do: - Use SSH Authentication - Disable Password Authentication - Use Fail2ban - Restrict on IP address (no need for fail2ban then) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit relay not utilising full capacity (even after months)
On 2014-10-29 09:41, Rejo Zenger wrote: [..] - So, the question is: why is it so much slower maximising the full bandwidth? The configuration from mid-July onwards is identical to the one in April. The only thing that has changed is in mid-August, when I moved to relay into a LXC container. However, that doesn't explain the slow pickup in mid-July to mid-August. Note that LXC likely does not give you the security properties that you expect. issue this in your container to shutdown the host: echo b /proc/sysrq-trigger There is a bug open on this: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/645625 - And yes, I am aware of the Roger's blogpost. That does explain why the node may be slow to pick up traffic, but it doesn't explain why it was a lot faster in doing so in April then in mid-July. There are some weird properties in trying to do full-bandwidth. Deterministic it for sure is not. The IP is not mentioned in atlas: https://atlas.torproject.org/#search/94.142.240.243 Nor in: https://torstatus.blutmagie.de/ Though there is: https://torstatus.blutmagie.de/router_detail.php?FP=aa0d167e03e298f9a8cd50f448b81fbd7fa80d56 https://atlas.torproject.org/#details/AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 Is Tor 0.2.5.9-rc not outdated? You might be missing some features there. I see similar issues with other nodes btw, eg: https://atlas.torproject.org/#details/BDB26EF60A419089CA3AA0891AF1681455285D48 Though that is not an exit, which gives it a completely different metric. Are you also sure that coloclue likes you playing exit? (I can only assume so ;) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] UK Exit Node
On 2014-07-06 07:06, Michael Banks wrote: Any tips for UK Exit Node operators on a Residential ISP (BT)? I would be EXTREMELY careful in running an exit on a residential location. There is no way for you to prove that it was not you causing that connection but the Tor process causing that connection and thus some 'other' user. The UK government has all kinds of regulations/systems in place to protect children and to enforce copyright laws. They are also known to index/analyze all traffic. You might want to consider changing that into a relay instead as then you at least are not reaching out to a scary host (unless it also runs Tor). Also: 150.57.130.86.in-addr.arpa PTR host86-130-57-150.range86-130.btcentralplus.com. As such, it looks just like any other link, it has no relation to tor-relay.itschip.com at all. Except for folks with access to dnsdb, which law enforcement typically does have, but as DNS is not used in Tor, it is all irrelevant. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] UK Exit Node
On 2014-07-06 09:14, Michael Banks wrote: Advice taken I was debating to switch over to relay-only or not. I must note, the Tor node is on it's own address, under a residential contract. Does not matter. You cannot prove that you did not routed your connection over it or that it was or was not Tor. This is also why folks doing exit (and even relay) nodes use dedicated hosting: abuse does not cut of your home Internet link and there is a limited form of deniability (though that did not help for that Austrian guy it seems, then again he did a lot of other odd stuff too which probably did not help his case much... full facts are never known). I was taking extra precaution by running PeerGuardian and specifically blocking malicious IPs, and will continue to do so while I have a relay node. If you have a relay you will very unlikely be contacting anything on that 'list', at least through Tor. How exactly does PeerGuardian work? (seems there are a number of tools called that way and the first hit on google is unmaintained) Does it use a downloaded list, an RBL or something else? As when it is a list they are giving you the set of locations that are 'interesting' to peek at, when it is a RBL, they know who you are contacting. Unless a hash of some kind is involved you are likely giving away details or they are losing the details. I have tor-relay.itschip.com set in torrc.. guess I have to fiddle with more things? Anyone with Debian experience who can help in that field? Reverse DNS has little to do with the operating system, you'll have to ask your ISP to set that for you (who, if they allow then might inform you of a tool/protocol to use to do so). Typically though, for residential connections reverse DNS cannot be changed. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On 2014-05-13 23:09, grarpamp wrote: [..] *But we can bind to it and let users find it with their own openvpn scans close to (one up or down from) our OR IP.* Just use the standard openvpn TCP port on it. Thank you for suggesting the GFW folks now scan and/or directly block these IP addresses too. [..] The point is, we already own these extra IP's, and legitimate people are being blocked from services for no reason other than kneejerk or blind reactions to Tor via blocking services. Ahem, cloudflare, et al and other blocking 'services' well known to us. You are mixing the difference between an operator of a site selecting who their viewers are and a man-in-the-middle selecting that for both the user and the server. Don't mix those up. I am pretty-much-completely pro-Tor as there are good uses, but for controlling who logs in and who abuses you, Tor is a bad thing as you don't know what the source is. As an operator of a (server) site, being able to say sorry, we do not accept connections from Tor is a good thing, as there are situations where that is needed. [..] Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too As it can be done automatically, it is not more work for them. And actually, they are likely already scanning every IP in the /24 where a relay is located (well, actually they just scan the whole IPv4 space anyway, with zmap it is done very very quickly) but it's more work for them and they're unlikely to do it in any sort of global fashion. Especially since they can't prove it's part of Tor (because we don't publish the IP's as such). If the address space (eg the /24) does not contain anything normally useful they will just block it based on that. Instead of doing OpenVPN (which Wireshark knows and thus is easily detected by port number but also protocol itself), look at the variety of Pluggable Transports[1] people have been developing and deploy these. They are typically scan and protocol analysis resistant which will give much better bang for your buck. Of course, using BridgeDB is a good thing there to publish these details, or you could invent some new method of passing details to people (puzzle game solving ala captchas being a good start though defeatable by having slaving-away people getting paid for solving them). Greets, Jeroen [1] = https://www.torproject.org/docs/pluggable-transports.html.en ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help
On 2014-04-25 12:09 , David Stainton wrote: Let us know if/when obfsproxy runs on CentOS. Why would anyone want to use CentOS? Obviously this is a rhetorical question since there isn't a good reason to use CentOS instead of say Debian... AND if someone gave me access to thousands of CentOS servers for the purpose of running tor relays I would immediately want to change their distro to Debian. Or easier: make a chroot with in that a Debian install. Then you can run all Debian stuff easily, without having to bother with CentOS/RHEL/Fedora/etc... Just make sure that you disable most services and/or keep these upgraded. For a public relay you will want to do that anyway, as these hosts will be scanned by external friendly people. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ask Me Anything on Reddit about Tor
On 2014-03-11 08:13 , Jesse Victors wrote: ... Since I run some relays and a couple of exits .. From a trust perspective you effectively only run one (1) though ;). As they are operated by one entity and also are in the same location (IP-wise in the same /24), the latter will make Tor only use it once in a connection, thus either they will relay or they will exit or not use your set at all. Thus nothing bad there. You seem to also not have configured the Family field[1], you might want to do that. You did set the contact field similar; which makes me think, should Tor check that and maybe make a decision based on that info? (same as [1], baddies will avoid that). From reading the rest of the AMA, I think you did a good thing with answers! Great work! You might want to point to it from the Stackoverflow thingie: https://stackoverflow.com/questions/tagged/tor Greets, Jeroen (no time for reddit and similar thing, thus no acct, but otherwise you would have gotten a few points from me for that thread) [1] the jury is still out on this, as a baddies of course will not set it either and then it won't show up and afaik there was discussion on removing it as it does not help too much. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advise on fully using a gigabit connection
On 2014-03-05 17:51 , Jesse Victors wrote: Hey everyone. I manage an exit at a university, and I recently moved it to a gigabit connection. I did some tests and the machine does appear to be capable of fully using the available bandwidth. Besides getting two Tor instances to run side-by-side on the same IP, is there anything else I can do to further contribute the connection besides waiting and maintaining uptime? I set my average and burst bandwidth limits to the maximum upload speed I have been able to achieve in my tests, is that an ideal setting? Please advise. You'll need to run multiple Tor instances on different IPs (two per IP) as the Tor code is not parallelized internally enough unfortunately. See also: https://lists.torproject.org/pipermail/tor-relays/2013-September/002782.html for more details. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] External connections to port 9050
On 2014-02-27 23:12, Greg W wrote: I turned on some logging on my firewall today to help troubleshoot and issue and noticed a load of connections from external addresses to port 9050 on my exit node. I don't think that should be publicly accessible. Am I wrong about it being publicly accessible and does anyone else see lots of connection attempts on that port? 9050 is the standard relay port, as other relays connect to your relay (and then, likely, exit), it is quite logical that you see those connections. That is, unless you changed your port in torrc. Providing more details about your setup (or the node name, so that it can be checked in atlas.torproject.org etc) would be very handy to make any kind of further comment though. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
On 2014-02-24 09:32 , Zenaan Harkness wrote: I saw a hint of some interesting output by arm: flags: Exit, HSDir, Running, V2Dir, ValidleDebuggerAttachment 0' to your torrc and restarting tor. For more information see... This bit leDebuggerAttachment 0' to your torrc and restarting tor. For more information see... disappeared pretty quick. arm needs a few more details from Tor than it can easily get, effectively it wants to ptrace the Tor process to collect these details. Hence you'll need to set in torrc: DisableDebuggerAttachment 0 That will allow it to collect these details. See also the description for that option in: https://www.torproject.org/docs/tor-manual.html.en Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] reading the captchas
On 2014-02-10 15:16, eliaz wrote: Would it be possible for someone to change the captcha images at the URL for getting bridges, without of course lessening their effectiveness? The present ones are pretty much unreadable, to this human at least. - eliaz Just in case, it is not your eyes or brain that are at fault, that is indeed completely indeed unreadable for humans. And what I can decode from it, those are not 'words', they are groupings of random letters it seems. There is a ticket open about this though: https://trac.torproject.org/projects/tor/ticket/10809 Thus folks are working on resolving this, though it is a rather hard problem. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
On 2014-01-14 12:38, I wrote: Does anyone know how to get past this to get the exit running on Debian 6, please? Our clock is 6 hours, 48 minutes behind the time published in the consensus network status document (2014-01-14 11:00:00 UTC). apt-get install ntp would be a good start. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)
On 2013-11-11 19:23, Luther Blissett wrote: On Wed, 2013-11-06 at 14:00 +0100, Jeroen Massar wrote: On 2013-11-06 13:47 , mick wrote: On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén lars.noo...@gmail.com allegedly wrote: On 11/06/2013 01:26 PM, mick wrote: I disagree. Dropping all traffic other than that which is explicitly required is IMHO a better practice. (And how do you know in advance which ports get attacked?) Using reject instead of drop simplifies troubleshooting. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject Drop tends to get in the way. Again, I disagree. But I recognise that this can be a religious decision. My default policy is to drop rather than reject. I know that strict adherence to standards implies we should “REJECT” with a helpful ICMP error message. Configure your host with DROP, do an nmap, then configure it with REJECT thus for Linux: IPv4: -j REJECT --reject-with icmp-port-unreachable IPv6: -j REJECT --reject-with icmp6-port-unreachable Now repeat that nmap; indeed, for the DROP it is shown that these ports are filtered, for REJECT the ports are just 'closed'. Hence, the adversary did not learn anything in the REJECT case (services apparently are not there), but in the DROP case they learned that you have a firewall configured and that those services are likely there... Hence, not only is reject good for the user (as they do not time out connecting to the port), but it is also good against adversaries as they do not learn anything. I'd agree with the above logic if weren't 4 the f4c1 that OS fingerprinting I was not talking about OS fingerprinting; completely different beast. While nmap can do that, in this case nmap is just used as an example for service discovery. is done though the analysis of the packets your system sends in replying to scans - the way the kernel generates packet headers tells info on your system. So besides what others have said, I would also add that there is indeed a great difference of info your intruder can get from your system when it generates some kind of answer to random unpredictable requests when compared to no answer at all. As a ICMP Port Unreachable is a standard response, there is nothing the attacker will learn 'more' from this. It WILL learn when you DROP that you chose to block that specific port though and thus that there is likely something you are hiding there. If the attacker wants to know your OS it will learn that from the services and packets that you will allow in (and allow answers from). Though if you are paranoid about your OS then you are doing something wrong. Best solution: let a friend pentest your host without telling them what is and what is not there. (hence why the pentesting industry is a happy and well paid place) So I rather open only those ports to which I gave some love to and am willing to share, than just let my beloved machines to their own fate just to not let the =user= waiting for some seconds. I think the user can wait or close connection if impatient. If you have 1 user that is fine, if you have a thousand or several hundred thousands of users and they start calling you up, you will be changing that ;) Please note again that DROP/REJECT choice is a personal one. Each has advantages and disadvantages. If his interest on my machine was for just nano secs, I guess we can sidestep this whole gentleman's reply to a connection attempt. TCP connections do not time out that quickly. Put a DROP on a port and then try to connect to it using your favorite browser or telnet client. A scanner (nmap et all) will not bother waiting around, real clients will. As such you are hurting real clients, not the scanners; and again you are just telling the scanner you are hiding something. Also, I do not get this troubleshooting hassle. If you r the sysadmin u can write in time iptables rules, port scan, packet sniff and single out easily when it is network related or server software related. While *you* will be able to figure it out, the user's perception will be quite different. They connect, it times out. As such, The network is broken. And that is what they will call you with (and it can indeed be anything). While if they get 'connection refused', it is a much more clear message. PS: Try doing a packet sniff on a link with thousands of connections and where your user cannot tell you what source IP they have; next to the fact that they might just be using the wrong destination host... ;) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)
On 2013-11-06 13:47 , mick wrote: On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén lars.noo...@gmail.com allegedly wrote: On 11/06/2013 01:26 PM, mick wrote: I disagree. Dropping all traffic other than that which is explicitly required is IMHO a better practice. (And how do you know in advance which ports get attacked?) Using reject instead of drop simplifies troubleshooting. http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject Drop tends to get in the way. Again, I disagree. But I recognise that this can be a religious decision. My default policy is to drop rather than reject. I know that strict adherence to standards implies we should “REJECT” with a helpful ICMP error message. Configure your host with DROP, do an nmap, then configure it with REJECT thus for Linux: IPv4: -j REJECT --reject-with icmp-port-unreachable IPv6: -j REJECT --reject-with icmp6-port-unreachable Now repeat that nmap; indeed, for the DROP it is shown that these ports are filtered, for REJECT the ports are just 'closed'. Hence, the adversary did not learn anything in the REJECT case (services apparently are not there), but in the DROP case they learned that you have a firewall configured and that those services are likely there... Hence, not only is reject good for the user (as they do not time out connecting to the port), but it is also good against adversaries as they do not learn anything. As you say it is one of those 'religious' decisions, but in this, the facts show what should be preferred for multiple reasons ;) But, doing that can mean that incoming packets with a spoofed source address can get replies sent back to that (innocent) source address. DDOS bots exploit this behaviour. As there is no amplification (only a portion of the incoming packet is included) this is not used; there are much better sources of attack. Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] hardware accelerated crypto
On 2013-10-01 21:20, Andy Isaacson wrote: On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote: I'm not sure why I missed this first post but I'm very interested in working on this project with whomever is interested. I bought a pogoplug v2 specifically to test it's usefulness as a tor exit or relay. First step is, run openssl speed rsa and post the output to the list. While you're at it you may as well post the AES and SHA results as well. Heck, just run the whole openssl speed test (should take less than 20 minutes) and post the whole thing. :) Also details on what CPU/RAM it has, and information about the kernel and OpenSSL package you are testing, would be useful. dmesg output and the contents of /proc/cpuinfo may be helpful. Maybe a good idea to put the output in the wiki somewhere? Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Getting max bandwidth out of a relay
On 2013-09-12 11:06 , Andy Isaacson wrote: On Wed, Sep 11, 2013 at 05:13:04PM +0200, Jeroen Massar wrote: Are boxes that are doing these speeds running at a CPU or a network cap? Or maybe better asked, they do run at 100% usage of their cores or do they just use two/three cores to the max? There are three main sinks of CPU usage in a well-configured large Tor relay: 1. doing AES and SHA. This scales with the network bandwidth used. 2. doing Montgomery multiplication for circuit creation requests. 3. bookkeeping. (4. kernel TCP overhead etc.) [..] Thanks that explains a lot! Your boxes, with 12 cores and 70 GB of RAM, are quite a bit overpowered for running 500 Mbps of Tor. If you ran a Tor daemon per core, you'd be able to push around 2 Gbps of Tor traffic, easily. Awesome, that is good to hear, as then it should be able to fill the Gig-E pipe at least theoretically. As I am trying to avoid using too many IPs (IPv4 is constrainted, IPv6 is not, but the latter won't get much traffic), I'll try if I can get my tcp-balancer idea setup in the run of next week (low on spare cycles at the moment) and then forcing each Tor instance to use a specific core. At least, incoming should be easy that way; the question more becomes what outgoing traffic will do, especially the bit that sends details to the authorities, I'll see how that works though ;) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Getting max bandwidth out of a relay
TLDR: what do people to do get the max throughput through their boxes? Hi, This might be more tor-dev related (due to the Tor internals, eg why it does not use multiple CPU cores effectively etc), but is likely a bit more appropriate here as there are people who are able to get a lot of performance out of their boxes. I've been playing a bit with setting up a few relays and letting them push as much traffic as possible following amongst others the items at: https://www.torservers.net/wiki/setup/server Thus making sure it is using AES-NI (which turned off and then on made a bit of a difference but primarily in CPU load), and doing some TCP stack and other kernel tweaks. I am running the current-git Tor on them, thus self-compiled and except for the install path no special configure options (any tips there?). The boxes are 2-cpu 6-core E5645 @ 2.40Ghz, with HT thus 24 cores visible. Tor is using about 170% CPU (thus effectively 2 cores) on average along with 3G of mem, the box has 70G of mem thus that is not a problem. A little snapshot from 'arm' from one of the boxes: Bandwidth (limit: 3.9 Gb/s, burst: 3.9 Gb/s, measured: 353.9 Kb/s) Download (45.7 Mb/sec - avg: 27.2 Mb/sec, total: 302.2 GB) Upload (52.5 Mb/sec - avg: 27.9 Mb/sec, total: 308.4 GB): Down/Up varies upto 70mbit, the box has full GE and between them can push easily a single-stream 900mbit flow (tested with iperf/wgets/scp) next to the running Tor process. Thus there seem to be some significant issue in the Tor portion of things (though tuning might affect it as there are more flows etc). There is no connection tracking on the box, as that would just slow things down See also the munged torrc below, in case there are options to be set there. What else is there to tune except for maybe running multiple Tor nodes on the same box? Which would require it to use multiple IPs right as one can only run 2 nodes on the same IP I understand. Would there maybe be a way to run multiple Tor processes with the same key/identity but with a TCP load-balancer in front of it which distributes the incoming connections to the processes? The only thing then is that only one of them should report their details to the authorities and the others should not publish; would that be possible or would it mess up for instance performance stats? Greets, Jeroen -- torrc used: - NickName nick ContactInfo contact MyFamily $othernode ControlPort 9051 HashedControlPassword 16:pass CookieAuthentication 1 DirPort ip:port DirPortFrontPage /usr/local/tor/etc/tor/tordirport.html ORPort ip:port RelayBandwidthRate 600 MB RelayBandwidthBurst 606 MB SocksListenAddress 127.0.0.1 SocksPort 1080 ExitPolicy reject *:* #Log debug file /usr/local/tor/var/log/tor/debug.log Log notice file /usr/local/tor/var/log/tor/notices.log DataDirectory /usr/local/tor/var/lib/tor RunAsDaemon 1 DisableDebuggerAttachment 0 CellStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ExtraInfoStatistics 1 - /etc/sysctl.d/tor.conf net.ipv4.tcp_syncookies=1 net.ipv4.tcp_synack_retries=2 net.ipv4.tcp_syn_retries=2 net.core.rmem_max=33554432 net.core.wmem_max=33554432 net.ipv4.tcp_rmem=4096 87380 33554432 net.ipv4.tcp_wmem=4096 65536 33554432 net.core.netdev_max_backlog=262144 net.ipv4.tcp_no_metrics_save=1 net.ipv4.tcp_moderate_rcvbuf=1 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144 net.ipv4.tcp_fin_timeout=4 vm.min_free_kbytes=65536 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=10 net.ipv4.tcp_keepalive_probes=3 net.ipv4.ip_local_port_range=1025 65530 net.core.somaxconn=20480 net.ipv4.tcp_max_tw_buckets=200 net.ipv4.tcp_timestamps=0 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Exit flag given to nodes with nearly-all-reject?
Hi, Is the 'exit' flag given to a Tor node which only allows exit to a certain prefix? If yes, what kind of effect does that have on path selection, will it only be chosen for exit'ing to that prefix and not be used as a relay? Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why is my fast relay so slow to gain popularity?
On 2013-09-11 18:20 , Jesse Victors wrote: Hello everyone, newcomer here. I'm behind very fast connection (11.5 MB/sec down, 7.5 MB/sec up) (Most folks would just call that 100mbit, that is if your MB is MegaByte, hence why 11.5 MiB/s would be more accurate). thought that the Tor network could benefit from my connection, Definitely! especially since it's apparently been under high load recently. Per the latest blog posts, I downloaded the beta TBB and configured it as a relay under Linux. It's been up for almost two days now, yet it's still being utilized at a very, very small fraction of it's potential. This blog post from today explains the effect and reasoning: https://blog.torproject.org/blog/lifecycle-of-a-new-relay In the network map, I see that my relay has an advertised speed which is again much slower than it actually can be. IMHO that label should be changed to 'measured speed' as the bwauths take care of that now. To my knowledge, a web server can be put under full load right away, and distributing computing projects use the most of your computer right off the bat. Why doesn't Tor run computational and/or bandwidth tests and advertise my relay at a much more actual speed? The bwauths do that, but they don't run very often. I don't see why a fast relay has to start at the very bottom of the barrel to begin with. Because otherwise introducing a large set of fast relays and thus hurt anonymity. (On the other side a determined adversary just waits a bit longer) Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] huge increase in relay traffic
On 2013-08-30 20:39, Yoriz wrote: [..] Aug 29 23:19:59.000 [warn] Received http status code 504 (Gateway Time-out) from server '154.x.x.x:80' while fetching /tor/server/d/54BDF368367470FCBF015...067.z. I'll try again soon. Aug 30 00:14:52.000 [warn] http status 504 (Gateway Time-out) reason unexpected while uploading descriptor to server '154.x.x.x:80'). That likely is the following ticket: https://trac.torproject.org/projects/tor/ticket/8458 Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Weather - Node Down
On 2012-09-11 22:43 , torho...@tor.host-ed.me wrote: Hi, this is my very first post to this list. I operate tor exit relays vks24784 and vks24949 and subscribed to Tor Weather Reports. Now, at Sun, September 2, 2012 12:17 am and Thu, September 6, 2012 12:33 am, I received Node Down Reports for either of the nodes, 1st report for vks24949, 2nd for vks24784. That said, I noticed that these events reset the respective uptime counters at Atlas web application to zero Uptime is for the Tor binary. Thus if the Tor binary restarts uptime will go back to 0. (And thus when making config changes it is suggested to do a reload instead; of course for version updates you need to restart it and thus when tracking git you'll always keep a low uptime) and the nodes would lose the already earned stable, guard, named, etc. flags for a certain time period. They keep those flags as long as the node comes back quick enough. (I am not aware of what the value of 'quick enough' is, could be a day, could be less though). [..] I even checked the uptime through ssh and there hasn't been any reboots occurring. But what about the tor binary itself? Do a 'ps -ef | grep tor' and you will see the start time (STIME). Also, I'm wondering what actually would happen to guard, stable, named, etc. flags if I'd actually need to reboot the nodes cause of maintenance? Unless you keep the node offline for a longer time you will keep them. I feel it unfortunate to lose these flags (also for the Tor network itself(?)) and would like to ask: 1. What does Tor Weather consider a Node Down event? Please see: https://gitweb.torproject.org/weather.git/blob_plain/HEAD:/doc/design.txt Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
