- tor-relays - lists.torproject.org

significant rise in fail2ban alerts for ssh abuse
by Dirk 21 Aug '17

21 Aug '17

Dear all, we receive a significant rise of ssh login abuse mails which reach us and unfortunately our providers. By significant I mean an amount that starts flooding our abuse inbox. All abuse emails are structured the same way and point to Fail2Ban as originator. Do we have just bad luck and someone uses our severs to brute force all of SSH out there OR is there a new Fail2Ban or Linux distribution release which fosters or enables this fail2ban abuse mails be default ? As far as I know the functionality of Fail2Ban is old. If there would be a Linux distribution which enables this I would like to talk to the maintainer and let him know that he at least tries to read the correct abuse entry from ripe instead of bothering our provider as well. For a limited time we will now reject port 22. But really do not like this solution. I would rather like to find out the source of this rise in numbers. best regards Dirk Example 1 ---- Dear Sir/Madam, We have detected abuse from the IP address 1.1.1.x, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.) Note: Local timezone is +0300 (MSK) Aug 6 08:35:23 srv sshd[3534]: Invalid user admin from 1.1.1.x Aug 6 08:35:25 srv sshd[3534]: Failed password for invalid user admin from 1.1.1.x port 50789 ssh2 Aug 6 08:35:25 srv sshd[3534]: Connection closed by 1.1.1.x [preauth] Aug 6 12:26:03 srv sshd[28169]: Invalid user admin from 1.1.1.x Aug 6 12:26:05 srv sshd[28169]: Failed password for invalid user admin from 1.1.1.x port 35677 ssh2 Aug 6 12:26:06 srv sshd[28169]: Connection closed by 1.1.1.x [preauth] Example 2 ---- Dear Sir/Madam, We have detected abuse from the IP address 1.1.1.x, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. (If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.) Note: Local timezone is +0200 (CEST) Aug 7 17:41:14 vps3xxx sshd[32746]: Invalid user admin from 1.1.1.x Aug 7 17:41:14 vps3xxx sshd[32746]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.1.1.x Aug 7 17:41:16 vps3xxx sshd[32746]: Failed password for invalid user admin from 1.1.1.x port 60497 ssh2 Aug 7 17:41:16 vps3xxx sshd[32746]: Connection closed by 1.1.1.x port 60497 [preauth]

6 6

End of Life Relays
by nusenu 19 Aug '17

19 Aug '17

Hello relay operator, Please note that recently (2017-08-01) a few tor releases reached end of life and are no longer maintained (no security and bugfixes) [1]. Please consider upgrading to a supported release if you are affected. To find out whether you are running an end of life tor release you can search for your relay nickname on [2] or on https://atlas.torproject.org. As of 2017-08-19 still >9% of the tor network run on end of life releases. thanks for running tor relays, nusenu [1] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [2] https://nusenu.github.io/OrNetStats/eolrelays -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

bwauth in testing
by Tom Ritter 18 Aug '17

18 Aug '17

After suffering the loss of maatuska's bwauth several months ago, we have re-provisioned it thanks to the gracious help from https://coldhak.ca/ It has completed an initial scan of the network[0] and is reporting its data here: http://198.51.75.50/bwauth/bwscan.V3BandwidthsFile This week I intend to flesh out the remaining aspects of the bwauth (debug logging, alerting to detect downtime, get a proper domain name, ssl cert, etc) as well as do some sanity checking on its output. If all goes well, I'll submit it to maatuska for inclusion at the end of the week. But I wanted to announce it here, both to give an update, and let the community take a look at its output and see if anything looks fishy. The bwauths themselves tend to disagree, partly because of the eb and flow of network speeds and partly because they are designed to (they all measure from different network vantage points) - but they ideally are in some sort of rough agreement. -tom [0] "Measured 99.7% of all tor nodes (99.6% of previous consensus bw)."

3 4

r-pi tor relay fails after debian stretch update
by jah knee 18 Aug '17

18 Aug '17

hi i am running a relay on a raspberry pi v.1. it ran along just fine until i updated to debian stretch. i have reviewed the config to see what could be wrong, but i cannot find anything. this is what gets put in the logs over and over: Aug 18 09:52:41.000 [notice] Tor 0.2.9.11 (git-572f4570e1771890) opening log file. Aug 18 09:52:41.116 [notice] Tor 0.2.9.11 (git-572f4570e1771890) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f and Zlib 1.2.8. Aug 18 09:52:41.122 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Aug 18 09:52:41.122 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Aug 18 09:52:41.123 [notice] Read configuration file "/etc/tor/torrc". Aug 18 09:52:41.194 [notice] Opening OR listener on 0.0.0.0:9001 Aug 18 09:52:41.199 [notice] Opening Directory listener on 0.0.0.0:9030 Aug 18 09:52:41.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Aug 18 09:52:44.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Aug 18 09:52:45.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Aug 18 09:52:48.000 [notice] Your Tor server's identity key fingerprint is <X> Aug 18 09:52:48.000 [notice] Bootstrapped 0%: Starting Linux <hostname> 4.9.41+ #1023 Tue Aug 8 15:47:12 BST 2017 armv6l GNU/Linux i've been thinking about moving this node to another machine as i've read on this list how underpowered machines do not really help the network [i can't say i could repeat the details of the arguments, but they made sense to me when i read them]. but i'd still like to contribute ... any help or pointers appreciated. dankon

2 1

blocking >1 connections per ip address onto Tor DirPort
by Felix 17 Aug '17

17 Aug '17

Hi everybody >>> Does a particular Tor server/client will open more than 1 >>> connection at a time from to the DirPort ? >> If you're worried about denial of service issues on the DirPort, >> maybe the simple answer is to turn off the DirPort? I think the >> only real impact might have something to do with whether old >> clients believe that you're a usable guard. > understood - removed those iptables rules Good discussion. My experience is protecting the dirport makes sense to avoid ddos attempts. During my Debian times this rule worked fine for me: /sbin/iptables -A INPUT -p tcp -d $IPEXT --dport 80 -j ACCEPT -m limit --limit 5/s --limit-burst 50 On FreeBSB I go with something like: pass in on $IFEXT inet proto tcp from !<blockDIR> to $IPEXT port 80 flags S/SA keep state (max 150,max-src-states 50,max-src-conn 50, max-src-conn-rate 20/10,overload <blockDIR>) # release the blockDIR after some hours pfctl -t blockDIR -T expire 7200 # hourly cron job -- Cheers, Felix

1 0

Shirts
by Sebastian Urbach 17 Aug '17

17 Aug '17

Good Morning, I was asked recently by friends & family if i could get the traditional Tor shirt for them. I showed them the new Tor shirt and well let's say they really want the traditional shirt. Any chance to get it anywhere ? torservers.net is just offering size M /L and that's not going to work ... Thanks -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

2 2

Relay Operators Meetup at BornHack
by Alexander Færøy 16 Aug '17

16 Aug '17

Hello relay operators, DrWhax and I will host a small relay operators meetup at the upcoming BornHack festival in Denmark. If you happen to be around and want to join please keep yourself updated with the event schedule on the BornHack website or track the meetup event directly at https://www.bornhack.dk/bornhack-2017/program/tor-relay-operators-meetup/ :-) All the best, Alex.

1 0

What causes circuits to collapse?
by Igor Mitrofanov 16 Aug '17

16 Aug '17

Hi, I have configured a Tor bridge to go through a particular Tor guard relay (that I also own), as an experiment. Upon initialization I am getting this warning: "Your guard [fingerprint] is failing an extremely large amount of circuits. This could indicate a route manipulation attack, extreme network overload, or a bug. Success counts are 52/275. Use counts are 67/67. 268 circuits completed, 0 were unusable, 217 collapsed and 1 timed out. For reference, your timeout cutoff is 60 seconds". Both relays are running Tor 3.0.10. I have never received this warning before. How do I interpret the numbers above, and debug the issue? The guard is far from saturating its network bandwidth. It has 98% idle CPU and plenty of free memory. I am not running any attacks against it. It does use a tuned-up sysctl.conf but I have never had any problems with it. "tcpdump icmp" does not show anything interesting. There are no warnings in the guard's log. Thanks, Igor

2 1

Re: [tor-relays] keepyourprivcay: Introducing a new 100 mbit/s relay
by Keepyourprivacy 16 Aug '17

16 Aug '17

Another 100 mbit/s relay has been added, located in sweden. MyFamily entry set in torrc. https://atlas.torproject.org/#details/B92CADBD1E9A2F72E64D7DE5A1BF5B2B30DA7…

2 1

IXPs in the United States
by Christopher 14 Aug '17

14 Aug '17

Hello, Emerald Onion (https://twitter.com/EmeraldOnion) is researching Internet Exchange Points in the United States in order to bolster Tor relay deployments within our legal jurisdiction. We have blogged a list of IXPs we've identified so far: https://emeraldonion.org/internet-exchange-points-in-the-united-states/ Please note that Emerald Onion would not be the org to deploy more relays in other cities. We are interested in helping others in those regions become their own ISP. (See https://emeraldonion.org/development/ for related education.) 1. Are there any Tor routers connected to any United States-based IXPs? If so, which ones and who operates them? We know of at least four: a. Calyx Institute on NYIIX https://www.peeringdb.com/net/4594 b. XMission on Equinix Ashburn, SIX Seattle, and SLIX https://www.peeringdb.com/net/789 c. Riseup Networks on SIX Seattle https://www.peeringdb.com/net/9021 d. Emerald Onion on SIX Seattle https://www.peeringdb.com/net/14010 2. Is this IXP friendly to Tor? 3. What is the organizational structure of this IXP? Such as corporate-run or community-driven, etc. Please let me know if you have any helpful information. I'm also reachable via Signal. https://yawnbox.com/contact/ Cheers, Yawnbox

1 0