<div dir="ltr"><div><div>Hi Alex,<br><br>We are very sorry to hear
about the problems our measurements caused. Up until yesterday, we had
received no reports of them triggering these kinds of responses from
providers. However, yesterday we heard a very similar story from another
relay operator using Hetzner.</div><div><br></div><div>Thanks for
sharing your experience with the tor-relays community. We have also
updated our FAQ to inform contributors about this potential problem.</div><div><br></div><div>Also,
we'd like to help others avoid this while still providing useful
measurements, if possible. Have you gotten any feedback from Hetzner
about what rule was triggered and maybe how to avoid it? Do you have any
ideas about how one might stay below their radar? If it is something
simple like reducing the measurement rate that would be a great option
to prevent problems while still providing valuable data about the the
Tor network.</div><div><br></div>We do still hope that most relay
operators will be willing to give this project a shot. We have received
data from over 90 separate IP addresses and have gotten 2 negative
reports so far, although certainly the issues could be more widespread
without us being aware. We don't want to add to the headaches that can
result from running a Tor relay, but on the other hand Tor relay
operators are probably pretty adept at handling this kind of stuff. <br><br></div>Thanks<br><br>Anupam<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 5:02 PM, <span dir="ltr"><<a href="mailto:irregulator@riseup.net" target="_blank">irregulator@riseup.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello there,<br>
<br>
We're running a Tor relay (not exit) on a virtual private server at<br>
Hetzner for about a year. On Wednesday January 8th, we decided to take<br>
part in the "Trying Trusted Tor Traceroutes" [1] research experiment.<br>
There have been various calls for participation on public mailing lists<br>
[2] [3].<br>
<br>
The traceroutes were conducted using the scamper package, as suggested<br>
in README. We imposed no rate limiting to requests, just run the script<br>
with default values.<br>
<br>
Some hours later, Thursday 9th, we received an email from Hetzner<br>
stating that our server was taking part in attacks and they would<br>
suspend our instance if we didn't react within 8 hours. As soon as we<br>
got the warning we killed scamper conducting the traceroutes, and<br>
followed the procedure so as not to get our instance suspended. Hetzner<br>
also asked for some explanations about why we think our server was not<br>
taking part in the attack.<br>
<br>
We responded via email with a full explanation about the traceroutes<br>
from our server and the "Trying Trusted Tor Traceroutes" experiment from<br>
various researchers from University of Illinois [1]. We told Hetzner<br>
that our server was making harmless and legal traceroutes to various<br>
destinations on the Internet, thus they had no reason to suspend our<br>
instance.<br>
<br>
Twenty four hours later, Friday 10th, Hetzner blocked network access to<br>
the IP address of our server, did send us an email about blocking, but<br>
ignored our exlanations submitted the previous day. After the blockage<br>
of our IP we insisted on trying to resolve the case by sending one more<br>
email exlaining the situation and asking to unblock us, and then opening<br>
a ticket. Hetner's response to the last email (5 hours later) was that<br>
we should open a ticket, which we already had done. Alas, our ticket was<br>
marked as duplicate and closed(?).<br>
<br>
During this loophole support nightmare most responses from Hetzner's<br>
part actually seemed to be machine generated. At last Hetzner asked us<br>
via email to send them a signed document via fax(!) containing<br>
explanations about the incident. Now that was ridiculous, since we had<br>
submitted explanations already three times with the first submission<br>
only four hours after Hetzner's first warning on Thursday. Nevertheless,<br>
we did resend the explanation.<br>
<br>
After about 7 hours of downtime, Hetzner unblocked network access to our<br>
server. More than 36 hours later they sent an email "Dear Mr. xxxx, your<br>
server is unlocked."<br>
<br>
Concluding,<br>
<br>
- Hetzner considers traceroutes to various internet destinations as<br>
attack. All relay operators with machines at Hetzner should be _careful_<br>
when taking part in "Trying Trusted Tor Traceroutes" experiment.<br>
<br>
- Hetzner has awful customer support.<br>
<br>
<br>
Cheers,<br>
Alex<br>
<br>
[1] <a href="https://web.engr.illinois.edu/~das17/tor-traceroute_v1.html" target="_blank">https://web.engr.illinois.edu/~das17/tor-traceroute_v1.html</a><br>
<br>
[2]<br>
<a href="https://lists.torproject.org/pipermail/tor-relays/2013-October/003113.html" target="_blank">https://lists.torproject.org/pipermail/tor-relays/2013-October/003113.html</a><br>
<br>
[3] <a href="https://lists.torproject.org/pipermail/tor-news/2014-January/000027.html" target="_blank">https://lists.torproject.org/pipermail/tor-news/2014-January/000027.html</a><br>
<br>
<br>_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
<br></blockquote></div><br></div></div></div>