Hi all,
I am the other user running into trouble with Hetzner participating in
the experiment using scamper.
Conclusion first: For my server at Hetzner tor trace route using scamper
at full rate was flagged as abuse but 1/5 (PPS=200) seems to be fine up
to now.
I started the script on Friday and shortly after got the first abuse
report. However in my case they did not block the IP in the end, even
though they sent me several machine generated abuse reports. Each time I
stopped scamper, sent them the explanation what the script was doing
together with the request to next time not flag it as abuse with no
effect whatsoever. Then I resumed scamper. Stopping was necessary
because their system only allows you to explain what was happening after
you "fixed" it. I also tried to call them but didn't succeed to get the
right people on the phone. The time frame they gave me for "fixing" the
problem was usually only a few hours.
Finally scamper was defunct, presumably due to being stopped two times,
so I restarted the whole Trusted Tor Traceroutes script on monday with
PPS=200 (reducing the traceroute rate to 1/5 of the default value). So
far I did not receive any machine generated abuse reports. I assume the
packet rate is now below the limit of what the monitoring thinks is a
netscan. I will report back if I should receive another abuse report
connected to the experiment.
"Netscans" are listed as unacceptable in the Hetzner server policy [1].
And since one can apparently not or only with great pains communicate to
a human in their support system there seems to be no chance of reliably
informing them why this does not qualify as a netscan.
For me a blocking of the IP would not be too painful since it looks like
they will block by IP. The IP belongs to an "experimental" KVM I run as
a sandbox to test things and which has nothing of importance running on
it. Therefore I will just continue running the script with the current
settings and see what happens.
Best regards,
Paul
[1] http://www.hetzner.de/en/hosting/legal/system-policies-rs
On 15.01.2014 06:00, Anupam Das wrote:
Hi Alex,
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.
Thanks for sharing your experience with the tor-relays community. We
have also updated our FAQ to inform contributors about this potential
problem.
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.
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.
Thanks
Anupam
On Tue, Jan 14, 2014 at 5:02 PM, <irregula...@riseup.net
<mailto:irregula...@riseup.net>> wrote:
Hello there,
We're running a Tor relay (not exit) on a virtual private server at
Hetzner for about a year. On Wednesday January 8th, we decided to take
part in the "Trying Trusted Tor Traceroutes" [1] research experiment.
There have been various calls for participation on public mailing lists
[2] [3].
The traceroutes were conducted using the scamper package, as suggested
in README. We imposed no rate limiting to requests, just run the script
with default values.
Some hours later, Thursday 9th, we received an email from Hetzner
stating that our server was taking part in attacks and they would
suspend our instance if we didn't react within 8 hours. As soon as we
got the warning we killed scamper conducting the traceroutes, and
followed the procedure so as not to get our instance suspended. Hetzner
also asked for some explanations about why we think our server was not
taking part in the attack.
We responded via email with a full explanation about the traceroutes
from our server and the "Trying Trusted Tor Traceroutes" experiment from
various researchers from University of Illinois [1]. We told Hetzner
that our server was making harmless and legal traceroutes to various
destinations on the Internet, thus they had no reason to suspend our
instance.
Twenty four hours later, Friday 10th, Hetzner blocked network access to
the IP address of our server, did send us an email about blocking, but
ignored our exlanations submitted the previous day. After the blockage
of our IP we insisted on trying to resolve the case by sending one more
email exlaining the situation and asking to unblock us, and then opening
a ticket. Hetner's response to the last email (5 hours later) was that
we should open a ticket, which we already had done. Alas, our ticket was
marked as duplicate and closed(?).
During this loophole support nightmare most responses from Hetzner's
part actually seemed to be machine generated. At last Hetzner asked us
via email to send them a signed document via fax(!) containing
explanations about the incident. Now that was ridiculous, since we had
submitted explanations already three times with the first submission
only four hours after Hetzner's first warning on Thursday. Nevertheless,
we did resend the explanation.
After about 7 hours of downtime, Hetzner unblocked network access to our
server. More than 36 hours later they sent an email "Dear Mr. xxxx, your
server is unlocked."
Concluding,
- Hetzner considers traceroutes to various internet destinations as
attack. All relay operators with machines at Hetzner should be _careful_
when taking part in "Trying Trusted Tor Traceroutes" experiment.
- Hetzner has awful customer support.
Cheers,
Alex
[1] https://web.engr.illinois.edu/~das17/tor-traceroute_v1.html
[2]
https://lists.torproject.org/pipermail/tor-relays/2013-October/003113.html
[3]
https://lists.torproject.org/pipermail/tor-news/2014-January/000027.html
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org>
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--
Paul Görgen
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays