1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Design For A Tor DNS-based Exit List
Status:
This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes.
See http://exitlist.torproject.org/ for an implementation.
Why?
It's useful for third parties to be able to tell when a given connection
is coming from a Tor exit node. Potential applications range from
"anonymous user" cloaks on IRC networks like oftc, to networks like
Freenode that apply special authentication rules to users from these
IPs, to systems like Wikipedia that may want to make a priority of
_unblocking_ shared IPs more liberally than non-shared IPs, since shared
IPs presumably have non-abusive users as well as abusive ones.
Since Tor provides exit policies, not every Tor server will connect to
every address:port combination on the Internet. Unless you're trying to
penalize hosts for supporting anonymity, it makes more sense to answer
the fine-grained question "which Tor servers will connect to _me_?" than
the coarse-grained question "which Tor servers exist?" The fine-grained
approach also helps Tor server ops who share an IP with their Tor
server: if they want to access a site that blocks Tor users, they
can exclude that site from their exit policy, and the site can learn
that they won't send it anonymous connections.
Tor already ships with a tool (the "contrib/exitlist" script) to
identify which Tor nodes might open anonymous connections to any given
exit address. But this is a bit tricky to set up, so only sites like
Freenode and OFTC that are dedicated to privacy use it.
Conversely, providers of some DNSEL implementations are providing
coarse-grained lists of Tor hosts -- sometimes even listing servers that
permit no exit connections at all. This is rather a problem, since
support for DNSEL is pretty ubiquitous.
How?
Keep a running Tor instance, and parse the cached-routers and
cached-routers.new files as new routers arrive. To tell whether a given
server allows connections to a certain address:port combo, look at the
definitions in dir-spec.txt or follow the logic of the current exitlist
script. If bug 405 is still open when you work on this
(https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll
probably want to extend it to look at only the newest descriptor for
each server, so you don't use obsolete exit policy data.
FetchUselessDescriptors would probably be a good torrc option to enable.
If you're also running a directory cache, you get extra-fresh
information.
The DNS interface
Standard DNSEL, if I understand right, looks like this: There's some
authoritative name server for foo.example.com. You want to know if
1.2.3.4 is in the list, so you query for an A record for
4.3.2.1.foo.example.com. If the record exists and has the value
127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list. If you get an NXDOMAIN
error, 1.2.3.4 is not in the list. If you ask for a domain name outside
of the foo.example.com zone, you get a Server Failure error[RFC 1035].
Assume that the DNSEL answers queries authoritatively for some zone,
torhosts.example.com. Below are some queries that could be supported,
though some of them are possibly a bad idea.
Query type 1: "General IP:Port"
Format:
{IP1}.{port}.{IP2}.ip-port.torhosts.example.com
Rule:
Iff {IP1} is a Tor server that permits connections to {port} on
{IP2}, then there should be an A record with the value 127.0.0.2.
Example:
"1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the
value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1
that allows connections to port 80 on 1.2.3.4.
Example use:
I'm running an IRC server at w.x.y.z:9999, and I want to tell
whether an incoming connection is from a Tor server. I set
up my IRC server to give a special mask to any user coming from
an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com.
Later, when I get a connection from a.b.c.d, my ircd looks up
"d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see
if it's a Tor server that allows connections to my ircd.
Query type 2: "IP-port group"
Format:
{IP}.{listname}.list.torhosts.example.com
Rule:
Iff this Tor server is configured with an IP:Port list named
{listname}, and {IP} is a Tor server that permits connections to
any member of {listname}, then there exists an A record.
Example:
Suppose torhosts.example.com has a list of IP:Port called "foo".
There is an A record for 4.3.2.1.foo.list.torhosts.example.com
if and only if 1.2.3.4 is a Tor server that permits connections
to one of the addresses in list "foo".
Example use:
Suppose torhosts.example.com has a list of hosts in "examplenet",
a popular IRC network. Rather than having them each set up to
query the appropriate "ip-port" list, they could instead all be
set to query a central examplenet.list.torhosts.example.com.
Problems:
We'd be better off if each individual server queried about hosts
that allowed connections to itself. That way, if I wanted to
allow anonymous connections to foonet, but I wanted to be able to
connect to foonet from my own IP without being marked, I could add
just a few foonet addresses to my exit policy.
Query type 3: "My IP, with port"
Format:
{IP}.{port}.me.torhosts.example.com
Rule:
An A record exists iff there is a tor server at {IP} that permits
connections to {port} on the host that requested the lookup.
Example:
"4.3.2.1.80.me.torhosts.example.com" should have an A record if
and only if there is a Tor server at 1.2.3.4 that allows
connections to port 80 of the querying host.
Example use:
Somebody wants to set up a quick-and-dirty Tor detector for a
single webserver: just point them at 80.me.torhosts.example.com.
Problem:
This would be easiest to use, but DNS gets in the way. If you
create DNS records that give different results depending on who is
asking, you mess up caching. There could be a fix here, but might
not.
RECOMMENDATION: Just build ip-port for now, and see what demand is
like. There's no point in building mechanisms nobody wants.
Web interface:
Should provide the same data as the dns interface.
Other issues:
After a Tor server op turns off their server, it stops publishing server
descriptors. We should consider that server's IP address to still
represent a Tor node until 48 hours after its last descriptor was
published.
30-60 minutes is not an unreasonable TTL.
There could be some demand for address masks and port lists. Address
masks wider than /8 make me nervous here, as do port ranges.
We need an answer for what to do about hosts which exit from different
IPs than their advertised IP. One approach would be for the DNSEL
to launch periodic requests to itself through all exit servers whose
policies allow it -- and then see where the requests actually come from.
References:
[DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for
E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November
2005.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
|
