Hi Paul,
            Great that you were able contact Hetzner. Now at least we know what is triggering their IDS. But I'm not sure we can work around this scenario because as you hinted- we don't know a head of time if certain IPs will be unrouted by intermediate routers. Moreover, their routing policies also change over time. We will have to think more elaborately on this. One simple solution might be to do traceroutes to only well known destination IPs but that would not give us the full picture.

But again thanks for your cooperation and its fine if you can't run the script due to Hetzner's IDS policy.

Thanks

Anupam


On Thu, Jan 16, 2014 at 10:32 AM, Paul Görgen <tor@pgoergen.de> wrote:
Hi again,

Hetzner now blocked my testing Server. This gave me chance to finally get into contact with a human person. They said their IDS triggered on "connects to unrouted IPs" (I assume that will be connects to unrouted IPs per time). I will try to convince them to set up an exception rule for my server but I am not too hopeful.

As a backup: I guess that there is no way to make sure that you don't try to connect to unrouted IPs, given that the IPs owner can decide to route or not route at will, right?

If both don't work I will not be able to run the script.

Best,

Paul Görgen


On 15.01.2014 23:23, Paul Görgen wrote:
Hi,

Apparently even with the lowered rate from time to time the abuse system
will complain.

I just received an abuse message from Hetzner even though now running
with the reduced rate. Just so you know. Next time this happens I will
try to escalate the problem by not solving it in the framework of the
automated abuse reports. Instead I will put the info about what I do
into the trouble ticket of the abuse message and put a strong plea to
contact me about if and how they can stop flagging it as abuse.

Best regards

Paul

On 15.01.2014 16:41, irregulator@riseup.net wrote:
On 01/15/2014 07:00 AM, 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



Hi again,

Anupam I wish I knew how to run the script and avoid any complaints from
Hetzner. Unfortunately Hetzner didn't give us any helpful info. We even
asked them explicitly if rate limiting would be a solution, but there
was no answer on that.

On 01/15/2014 02:20 PM, Paul Görgen wrote:
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.

Paul's answer may indicate that imposing a rate limit to the script's
requests might do the trick.

Greetings.
Alex



_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



--
Paul Görgen
Dieburger Straße 94a,            Mobile +4917620181608
64287 Darmstadt                 http://www.pgoergen.de
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays