Re: [tor-talk] RFC1918 addresses on outside interface

[temp5@xxxxxxxxxxx]

>>> > Running a non-exit Tor relay on Linux and have iptables set up to
>>> block
>>> > inbound and outbound RFC1918 addresses on the outside interface.
>>> Notice in
>>> > the firewall logs several seemingly random private IP addresses
>>> connection
>>> > attempts to my relay port getting dropped on the outside over the
>>> past few
>>> > months. The MAC address associated with these matches my ISP's
>>> default
>>> > gateway.
>>> >
>>> > Does Tor do some type of loopback on the outside int.? Or is my ISP
>>> doing
>>> > something peculiar with NAT?
>
> Regarding RFC1918 observations...
> ISP's with clue are supposed to do reverse path filtering on
> their customer connections (src), and not route 1918 space
> beyond their borders (dst).
> It is more likely to see 1918 space in src addresses on the net
> because some ISP somewhere forgot RPF.

I think this is the case- that my ISP forgot. Either that, or they are
being cheap and giving other customers private IPs and NATting Internet
traffic for them. It would sort of work, unless they attempt to access an
Internet resource (like my Tor relay) that happens to be inside their own
network.

> And common to see 1918 in dst addresses if you're hosted
> in some amateur datacenter that hasn't figured out VLAN's.
> Most ISP's and transits with clue block it all as well as
> a bunch of other nonsensical bogons.
>
> Just block all inbound 1918 packets (whether it's in src and/or dst),
> and everything not addressed to you via the wan interface.
> And make sure you're not leaking your own 1918 space to
> your provider.
> Special care of your modem/bridge management and any dhcp
> may be needed.

Am block it both ways, that's how I noticed this traffic in the first
place! :)

>>> Assuming it's my ISP, is there any way to configure my relay to
>>> discourage
>>> clients in my AS from using it as an entry point?
>>
>> Could you say more about why you would want to do that? I ask because
>> this increases those clients' risk from an AS-level attacker by
>> mandating an increase in the number of ASes that must be traversed
>> between client and entry node.

Since I'm just dropping the invalid traffic, it would save time on the
clients ends if they contacted a relay other than mine. I'm on a
relatively small ISP, so it's just a handful of clients that would be
affected though.

> / Conversely, entering through a relay in your own AS means that somebody
> / can definitely see all of your traffic and all of your entry node's
> / traffic. Is that really better?
>
> It's still encrypted traffic, not plaintext. Your cable/dsl operator AS
> has no interest in being a passive adversary itself. Though it may
> partner with an actual PA who can see beyond just that AS anyways.
> _______________________________________________

Thanks for the feedback, all. I'll just ignore the log entries, and maybe
followup with my ISP on what they are thinking/smoking.


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