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

[grarpamp <grarpamp@xxxxxxxxx>]

>> > 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.
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.

>> 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.

/ 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.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk