- tor-relays - lists.torproject.org

Re-installed Tor relay node as exit node with same name, different OS.
by Seth 19 Nov '14

19 Nov '14

I recently re-installed the operating system for a VPS that was running Parabola GNU/Linux and acting as a Tor relay. The new OS is OpenBSD 5.6 running tor-0.2.5.10. Instead of running as a relay I modified torrc so it runs a ReducedExitPolicy policy. Initially there were several problems with Tor exit node traffic being blocked by the firewall which has since been resolved. The Tor status page however still does not list this router as an exit node. http://jlve2y45zacpbz6s.onion/router_detail.php?FP=e1e1059d8c41fc48b823c6f0… Any ideas why? -- Seth I <3 nicely trimmed email replies

2 2

BSDNow, OpenBSD Journal
by Libertas 19 Nov '14

19 Nov '14

1 0

List of Relays' Available SSH Auth Methods
by Libertas 19 Nov '14

19 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, everyone. Linked below is a list of relays that were live last night along with the SSH authentication methods they support: https://gist.githubusercontent.com/plsql/27e80e6dab421f8cba6c/raw/8bb0c7aa9… If no auth methods are listed, the SSH connection to the relay failed (more on that below). I used this script to generate it: 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. Generally, it is far more secure to allow only public key auth. The Ubuntu help pages have a good guide on setting up key-based auth: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Be sure to disable password authentication after you get key-based auth working! https://help.ubuntu.com/community/SSH/OpenSSH/Configuring#disable-password-… To test whether password auth is still supported, use my script (the README is pretty thorough) or try SSHing from a machine that doesn't have access to your private key. In the latter case, you should get the response 'Permission denied (publickey).' immediately. If you're having issues, make sure that you've restarted sshd since the last time you changed the config. Be sure to back up the node's secret key or your SSH private key, but only somewhere safe! For example, store it in a password manager database on Tarsnap or a USB. This script doesn't attempt any kind of authentication or unauthorized access, so it's about as benign as network scanning scripts come. Regardless, let me know if you have any concerns. It made successful SSH connections with 2839 / 6551 relays. Reasons for failure include: * 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. * 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?). * The server going down between when I downloaded the consensus and when I ran the script. * My VPS's IP address getting added to a shared blacklist that the server uses. * etc. If I gave any poor advice or got anything wrong, please let me know. Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUa2ExAAoJELxHvGCsI27Np8IP/2duANtd55hs5L9IskFD2REe 9x5TR+uwZ54GhYLiFc+qiX3JnfoxfurZW7vi++D4R3E9L7nGo5weEZd0b88yJ6kx fUT9QG8gq2RFYdG+RQgYoEI9mLNObK/uc6J9qV3Y7dLOE/may6t6BDWpQTh7g5BJ 8fOnhrqjs0JdfTldc6xzrHT+m1dKBpylWus/WwGaJBReKOx6v7FoMEY53qowK0iA Vb5QS4idYb5WWF+K3Uzqk56v6sUzds/LTTlVc/R6mxjdse4AiMXO3DZsEffhI95W 8xSuw45e/Cfv/j80njsm4O1gFnrqyv/KcGwmL7vNPmtH4+i6dijTbBRroVElm1o3 LQBgCdUmQLz7njeprKnw8xdKT9X3oht4p9VZDfqWogXGiqRRdEtQCVUVhJp+ZrPA KrJBtV/IbYxyndhzC5cMAcTQUff0SOvDtzFnC4cxUbxSemtuO1NMwnIZtv3aGmG5 NEfXS3RjaUlZeZPZuymBDL1CnFqki6+eBDvka8ZOhL1/BgmDqcgT7nRWhlC5MtCG wBAfuJWB8BZl2PHg66VUN9X05TeHbVmrlyuRXaZO6SZof0Wp5vPjzJ1mKD6AyTlt Y/7liLapWgCVSYldohvbLB016iO/aHyGf3oTvZqUyG3NyD267aRQCDQ+sZZq7Cdz +eQO5eJLW/gFNXEptaJz =alRk -----END PGP SIGNATURE-----

19 30

Call for obfs4 bridges, and a brief discussion of obfs4proxy.
by Yawning Angel 18 Nov '14

18 Nov '14

Hello everyone, As people who have been following Tor Weekly News or other news sources, I have been working on a new pluggable transport in the obfs-line to better allow censored users to reach the Tor network. The result, obfs4 is what I would consider ready for general deployment[0], and as part of the process there needs to be bridges for the users. To entice people to run obfs4 bridges, I would like to talk briefly about obfs4 and obfs4proxy. I am also planning on doing a blog post about obfs4 some time after I regenerate my experimental TBB snapshots. On obfs4: obfs4 is the next up and coming pluggable transport in the obfs[2,3] line, though in terms of design, a better name would be "ScrambleSuit 2". The main difference is the switch from UniformDH to ntor-with-Elligator2 for the key exchange process, which means that clients strongly authenticate the identity of the bridge (The key exchange succeeding means that the bridge possesses a Curve25519 private key that is known only to the bridge). Additionally the ntor handshake (even with the Elligator2 transform in the picture) is considerably faster than UniformDH which should increase scalability. On obfs4proxy: obfs4proxy is the current obfs4 reference implementation, written in the Go programming language. The use of Go was primarily driven by the availability of an Elligator2 implementation at the time, though it also has other practical benefits over writing it as a component of the python obfsproxy code, for example, it is trivial to run bridges listening on ports < 1024 on modern Linux systems. obfs4proxy implements support for obfs[2,3,4], as a managed tor pluggable transport (no standalone mode currently). Note that obfs2 support is for backward compatibility purposes only and it is discouraged that new obfs2 bridges are run as the protocol is trivially broken by most adversaries. In terms of code stability, we have been running one of the Tor Browser's default obfs3 bridges on obfs4proxy for quite a while with no issues. Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x, otherwise the bridge lines that are published will be useless[1], though people that wish to run obfs3 bridges with obfs4proxy naturally can do so with tor-0.2.4.x. Source: https://gitweb.torproject.org/pluggable-transports/obfs4.git Debian packages (Thanks Lunar!): https://packages.debian.org/sid/obfs4proxy Note: I just tagged/pushed obfs4proxy-0.0.2, but the only significant change is that it is easier to get an obfs4 bridge line to give out to people as the bridge operator. I expect packages to catch up as the wonderful packager has the time. Questions, comments, and bridges appreciated, -- Yawning Angel [0]: https://trac.torproject.org/projects/tor/ticket/12130 [1]: https://trac.torproject.org/projects/tor/ticket/13202

5 12

FYI: ISP's and blocked Authorities
by Sebastian Urbach 17 Nov '14

17 Nov '14

Hi, It seems to be the case that a few ISP's are not up to date and still using old IP's to block Authorities. That means if you are able to connect to just 1 or 2 Authorities but not to all of them your ISP could be one of those candidates. I saw this behaviour in one case just today. Connectivity with Gabelmoo and longclaw was possible but no other Authority was reachable. Gabelmoo recently changed the IP and longclaw is brand new afaik. That ISP is clearly using an old list of IPs to block Tor for their VPS systems. What makes it even worse is that this system was going to be a Non-Exit relay :-( I will ask the operator for more details and the good/bad ISP page will be updated accordingly. If you can reach some Authorities (not all) and you are not getting indexed and measured (also you can't find your system on the Atlas / Tor site), this could be the reason why. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 4

Re: [tor-relays] Obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 15 Nov '14

15 Nov '14

OK, I updated the obfsproxy apparmor profile so it works for both standalone and managed obfs3. Needed to add a line to /etc/apparmor.d/local/system_tor too. Profiles below and included in the attachment along with an init.d definition. /etc/apparmor.d/usr.bin.obfsproxy ------------------- #include <tunables/global> # vim:syntax=apparmor /usr/bin/obfsproxy { #include <abstractions/base> #include <abstractions/python> network inet stream, /dev/random r, /dev/urandom r, /etc/nsswitch.conf r, /etc/passwd r, /usr/** r, /usr/bin/obfsproxy rix, /var/log/tor/obfsproxy rw, signal (receive) set=("term") peer=system_tor, } ------------------- /etc/apparmor.d/local/system_tor ------------------- # Site-specific additions and overrides for system_tor. # For more details, please see /etc/apparmor.d/local/README. signal (send) set=("term") peer=/usr/bin/obfsproxy, -------------------

1 0

iptables / dump
by Sebastian Urbach 15 Nov '14

15 Nov '14

Dear list members, My iptables dump, as promised (v4). Updated every hour and available as long as my relay is alive ;-) I run a pretty tight ship, just one ssh user and harsh fail2ban settings. All these listed IP's are considered to be "the usual suspects". Please feel free to use it, should give you a jump start. It is getting pretty quiet now since i passed the 300+ ip's milestone. Download: https://www.urbach.org/~sebastian/rules.v4 -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 5

Re: [tor-relays] iptables / dump
by Sebastian Urbach 15 Nov '14

15 Nov '14

On November 15, 2014 2:33:23 PM Libertas <libertas(a)mykolab.com> wrote: Hi, > > Honestly, the safest thing to do is to NOT USE PASSWORD BASED > > LOGINS. Im aware of that. > I wrote a script to scan the Tor network for password-based login > availability. If I have the time and no one beats me to it, it'll lead > to a site that warns relay operators about security problems with > their servers. For example, I can combine it with basic, non-invasive > nmap results to warn about non-essential network applications, old OS > versions, and old Tor versions as well. Awesome, like to see that. Sebastian

1 0

Graph not updating.
by Kevin de Bie 14 Nov '14

14 Nov '14

Is there any paticular reason the bandwidth graph flatlined since last night? My ISP may have had some maintenance but my TOR relay is purring like a kitten again, data throughput is quite formidable at the moment at around 1mbps. I use orbot on android.

1 0

Relay's clock settings off no matter what
by Austin Bentley 14 Nov '14

14 Nov '14

Hello everyone, I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings: >05:56:12 [WARN] Received directory with skewed time (server '154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often): >02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data. Could someone shine some light on this? Thanks, Austin

7 9