[tor-relays] Strange BGP activity with my node

Trevor Ellermann trevor at ellermann.net
Mon May 14 17:39:21 UTC 2018


Thanks for the responses. To follow up this is how the offending ISP
responded to our inquiries. I do not believe any further follow up is
necessary.

*snip*
Thank you for getting in touch.

I am afraid an engineer made an error in the BGP configuration of one of
our devices earlier this afternoon, which resulted in a number a host
routes being inadvertently announced to certain of our upstream providers.

The route itself existed as part of a set of prefixes internally routed to
null on our network.  This particular IP hosts a TOR relay node, and while
that is perfectly legitimate we have a business requirement to block access
to these internally:

https://metrics.torproject.org/rs.html#details/
383D6E34D9BEA92E97092B134A708EEF476DF2E4

The route should never have been announced outside our own AS.
Unfortunately due to human error it was advertised earlier today (May 9th)
from approx. 11:04 to 11:10 UTC.  I can assure you this was an
unintentional error, we had no desire to interrupt or affect communications
outside our AS.  The mistake was quickly spotted by our own NOC team and
reverted.

I hope you can accept our sincere apologies for this issue, we have taken
steps to ensure that any similar mistake will not have such impact in
future.
*snip*

On Wed, May 9, 2018 at 11:54 AM, grarpamp <grarpamp at gmail.com> wrote:

> On Wed, May 9, 2018 at 2:06 PM, Trevor Ellermann <trevor at ellermann.net>
> wrote:
> > I just a notification from my data center that someone is trying to
> hijack
> > the IP of my exit node. Seems like the sort of thing someone might do
> when
> > trying to attack Tor. I'm in a very remote area with limited access but
> any
> > suggestions on actions I should take?
>
> Make sure your box and keys aren't compromised.
> If that's ok, best they can do if the announcements are
> listened to is camp on the ip for a while using their own keys,
> (there might be some identification attacks made possible with
> such a transient reroute,) circuits would fail till the consensus
> updated to them, but there could be some duplicate ip split horizon
> issues involved due to filtering.
> If they hacked the boxes there's hardly need to expend noisy
> reroutes when they can do most attacks using the box itself.
>
> Hop on the route servers or your other favorite interfaces
> to the net and analyze who all is announcing /32's trying to
> cover any other tor nodes.
>
> Sane isp's will filter such things without prior coordination. It's fairly
> rare,
> and for them to bother giving customers courtesy reports. Though
> depending on nature of ticket / relationship with GBLX, you might want
> to reply saying you've never worked with Asavie and don't approve
> of the action regarding your IP.
>
> You can also search AS200005 to see what kind of heat
> they catch from other operators / internet analysis tools.
>
> > ====================================================================
> > Possible Prefix Hijack (Code: 10)
> > ====================================================================
> > Your prefix:          204.17.32.0/19:
> > Prefix Description:   GBLX-US-BGP
> > Update time:          2018-05-09 12:11 (UTC)
> > Detected by #peers:   1
> > Detected prefix:      204.17.56.42/32
> > Announced by:         AS200005 (Asavie Technologies Limited)
> > Upstream AS:          AS200005 (Asavie Technologies Limited)
> > ASpath:               200005
> >
> >
> > https://torstatus.blutmagie.de/router_detail.php?FP=383d6e34
> d9bea92e97092b134a708eef476df2e4
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180514/72aeadbd/attachment.html>


More information about the tor-relays mailing list