Re: [tor-relays] lets increase Tor's IPv6 exit capacity: list of IPv6 exits that do not allow IPv6 exiting (outdated tor or missing torrc option)

[Aaron Hopkins]

On Tue, 4 Apr 2017, nusenu wrote:


If you are on this list:
Make sure you run tor version >=0.2.9.10/>=0.3.0.3-alpha
and have 'IPv6Exit 1' in your torrc.


I am on this list.  I just updated from 0.2.9.9 to 0.2.9.10 and already had
"IPv6Exit 1" in my torrc.

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

Re: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")

[Aaron Hopkins]

On Thu, 13 Aug 2015, Mike Perry wrote:


As such, I still look forward to hearing from someone who has worked at
an ISP/University/etc where this is actually practiced. What is in
*those* logs?


I can speak to my experience in that capacity.

As an ISP, I need to be able to answer questions about the data flowing
through my network, such as:

- What if scenarios for capacity planning, peering, etc that require me to
understand how much traffic (in bits/sec at 95th percentile) is coming and
going to each BGP prefix (route).

- Be able to shut down customers that are attacking the outside world and be
able to classify the type of attack.  To do this, I need to be able to
differentiate good traffic from attack traffic somehow.

- Be able to quickly blackhole customer IPs that are taking a volumetric
DDoS attack that is sufficiently large to threaten my other customer's
connectivity.

- Be able to bill customers for the quantity of bandwidth that they use. 
For most ISPs, this comes from per-port counters, but ISPs that bill

differently for peering traffic or for international traffic need more
detail on bandwidth sent per customer to various destinations.

- Be able to track a given connection back to a customer to be able to react
to abuse complaints for at least a few weeks.  In my environment, I can
just look at which IPs are assigned to a port, but other ISPs will need to
consult DHCP logs.  Some ISPs do NAT at the ISP level, and if a single IP
can be used simultaneously by multiple customers, they may need to keep
per-connection logs.

Netflow is the standardized way to collect packet header information to be
able to answer all of the above and from what I can tell is in use by at
least a significant fraction of ISPs.  There are a few options to capture
netflow data:

- Limited netflow capability is built into all of my big routers, and is
probably the easiest to set up.

- If doing the netflow collection on the router itself is not viable, either
port mirroring or specialized copper or fiber network taps can easily send a
copy of all traffic to a collector box running something like nProbe
(http://www.ntop.org/products/netflow/nprobe/).

The netflow record format will be something like on of these:
http://www.cisco.com/c/en/us/td/docs/net_mgmt/netflow_collection_engine/3-6/user/guide/format.html#wp1006186

The default netflow logging is per-flow, so one record will be saved per
{protocol, source IP, source port, destination IP, destination port} tuple
per 5-30 minutes.  Connections that live longer than the flow timeout will
span multiple records.  Timestamps are second granularity, and TCP flags are
ORed together, so you can tell whether the connection
started/ended/continued based on the TCP flags.

I try to avoid storing any raw per-flow data to disk.  At the scale I'm
operating, I can't store it for very long, and walking through it again is
too slow.  If I wanted to throw more hardware at netflow log processing,
it's at least possible to do, though.  Of the people I've heard doing this,
they are mostly paranoid companies (not ISPs) who want to be able to trace
security incidents after the fact.

Instead, I try to only store much smaller aggregate data, such as packets
and bytes sent and received per 5 minutes to and from each /24, and the
results of the netflow-based attack detector, which processes the flows as
it gets them.

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

Re: [tor-relays] amount of unmeasured relays continuously rising since 2 weeks

[Aaron Hopkins]

On Mon, 18 May 2015, Roger Dingledine wrote:


I've even been pondering crazy hacks at this point like exporting moria1's
bwauth file to a second dir auth, so it gets to vote twice and we're more
likely to have the required minimum of three opinions for each relay.


Are the existing bwauths down, or are they just falling behind?  I think I
read something last year suggesting that they were taking more than 18 hours
to get through a measurement run, and the data was only allowed to be 24
hours old.

If they are just falling behind, could the consensus be based on the 3 most
recent measurements instead, however old those are?

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

Re: [tor-relays] Please enable IPv6 on your relay!

[Aaron Hopkins]

On Wed, 13 May 2015, Moritz Bartl wrote:


In short, you add:

ORPort [IPv6::address]:port
IPv6Exit 1
ExitPolicy reject6 *:*

(or a more open exit policy respectively)


I tried configuring this a while ago, but got confused by what appeared to
be conflicting documentation for IPv6 exit policies.  Is the ExitPolicy for
IPv6 completely separate (only using accept6/reject6 lines) or does it also
make use of lines like "ExitPolicy accept *:80" which mention a port but not
an IPv4 IP?

-- Aaron

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Aaron Hopkins]

On Sun, 3 May 2015, Matthew Finkel wrote:


Assuming the path to their data dir is /var/lib/tor, we ask them to run:


Please don't get in the habit of asking relay operators through e-mail to
run complex bash command lines as root.  As a security practice, this is
terrible.  (How do you know the suggested command wasn't altered before it
reached its recipient?)

If you want to build a utility for this into the tor distribution, and make
it obvious what it does, I think that's fine.  If the site asked people to
run "tor-request-tshirt" or more generically "tor-verify-ownership" and it
asked for whatever required information, I'd think that'd be more obviously
safe.

Or as Robert suggests, just send verification mail to the listed contact
address of the relay.  If they don't list one on their config, find an
alternate verification mechanism like e-mailing whois contacts for the IP or
domain name, or refuse the request.

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

Re: [tor-relays] Tor bridges on borrowed ports

[Aaron Hopkins]

On Fri, 2 May 2014, k...@mailtor.net wrote:


*) dark iptables nat magic


You can do source+destination NAT (aka "hairpinning") using only the
iptables command, which is often installed already on most Linux boxes. 
This is the equivalent of having a port-forwarding TCP proxy.


Assuming your external-facing interface is eth0, you want to forward your
local TCP port 5432 to the remote IP 2.3.4.5 on port 6789, this would be:

  iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5432 -j DNAT 
--to-destination 2.3.4.5:6789

  iptables -t nat -A POSTROUTING -d 2.3.4.5 -o eth0 -j MASQUERADE

You also need to enable IP forwarding, which can be done in a distribution
specific way, or directly with:

  sysctl net.ipv4.ip_forward=1


Can I announce an address that isn't directly mine? Can I use my address
for outbound traffic to the next relay or do I need to use the "bridge
address" for that?


I don't know about the announcements, though.

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

Re: [tor-relays] Tor relays and exits exposing Privoxy publicly

[Aaron Hopkins]

On Sun, 10 Nov 2013, Claudio wrote:


You're right, just a few actually do proxy. With a few seconds timeout
only 162.243.5.88 and 78.47.41.125 do to me at the moment.


Good to know.  I don't see a contact for 162.243.5.88 and I sent mail to the
contact address listed for 78.47.41.125 in September but didn't get a
response.


Just out of curiosity, what would be the reason for leaving such port
open but inactive?


For me, it is to try to waste TCP sockets and OS threads of whichever botnet
is trying to hit 8118 on all Tor nodes over and over, in an effort to slow
them down.  Though I'm currently holding open 43000 connections from them, I
don't think it has had much of an effect, unfortunately.

See http://en.wikipedia.org/wiki/Tarpit_(networking) for more background. 
It talks about IP-level and SMTP-level tarpits, but my HTTP tarpit is

similar in theory, but operates at the HTTP protocol level.

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

Re: [tor-relays] Tor relays and exits exposing Privoxy publicly

[Aaron Hopkins]

On Sun, 10 Nov 2013, Claudio wrote:


Host: 66.180.193.219 (tor-proxy.die.net)Ports: 8118/open/tcp//privoxy///


Want to make HTTP requests through these ports and see who will actually
proxy content for you?

If you try making a request through this port on tor-proxy.die.net, it won't
proxy but rather will take as long as possible to send you a bogus 10 meg
reply, acting as what is known as a "tarpit".

In September, I sent a note privately to the contacts of the other 19 Tor
nodes that had an open 8118 port, and 5 or so fixed their configs.  A few
more replied saying that they had all ports open intentionally but weren't
really passing traffic.

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

Re: [tor-relays] Traceroute measurement from Tor relays

[Aaron Hopkins]

On Wed, 23 Oct 2013, Karsten Loesing wrote:


As you may be aware, the anonymity of a connection over Tor is vulnerable
to an adversary who can observe it in enough places along its route.


Are you trying to work backward to physical-layer chokepoints, like how the
inter-contentinal network topology maps to the landing sites on
?


Basically the experiment does traceroutes to three groups: all
"routable IP prefixes", all Tor relays, and then all /24 subnets.


Based on my read of your input data, these will run traceroutes to 491762,
9058, and 13597431 IPs respectively, sending at least 100 million packets?
This is a bigger ask than I think you made clear.

I question the utility of scanning all /24s.  By definition, all /24s in a
BGP prefix take the same path to its origin AS; the only variation will be
within that.  If you are looking for chokepoints, you've already found it
with the origin AS.

This also does all scans sequentially, which will have a couple of negative
side-effects.  You are much more likely to trigger ICMP response
rate-limiting on intermediate routers and more likely to trigger IDS alarms
than if you'd randomized your target selection.  Running your target list
through one of the following would mitigate this:

awk 'BEGIN{srand()}{print rand()"\t"$0}' | sort -k1 -n | cut -f2-

perl -MList::Util -e 'print List::Util::shuffle <>'

sort -R


These kinds of measurements are not uncommon, and they will not be
done at a high rate.


They are uncommon from a Tor exit node, which already receives enough
complaints where it is really helpful to be able to truthfully claim to my
ISP and others that none of the traffic was generated by me, there's not
much I can do to stop it, and I have no logs about anything.


If you are not able to run scamper, the script will also work with the
more-common but less-accurate and slower "traceroute" utility.


Which by default will try to keep 128 traceroute processes running all the
time.  This is potentially problematic for relays with limited RAM or CPU
available.  I'd recommend making this more clear.

I may run this from a machine on the same network as my Tor node, but
definitely not on the Tor node itself.

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

[tor-relays] Sent open privoxy port warning

[Aaron Hopkins]

I sent the following warning to the listed e-mail address of 14 of the 19
Tor nodes I found that accepted connections on port 8118, some of which
bounced.

If any of you run or know how to get in touch with the operators of the
nodes DaJoker, FawkesSwissBlade, LUDICROUS2U, RaspberryPI, pangu,
mouseHouse, tornonym, or 75.137.122.118, I'd appreciate if you could pass
this along.

Thanks!

-- Aaron

---

I noticed your Tor node _ with an IP of _ is one of 19 nodes that accepts
connections publicly on TCP port 8118, which is the default port for
Privoxy.  I suspect this might be a configuration mistake.

I'm investigating this because my tor node "tordienet" has received millions
of HTTP proxy requests to port 8118 per day for months.  The requests appear
to come from a botnet running on roughly 1500 IPs, and seem to be
advertising click-fraud related.  From the discussion in July on the
tor-relays@lists.torproject.org mailing list (archive at
https://lists.torproject.org/pipermail/tor-relays/), this appears to be true
of many nodes.

Port 8118 is the default port for Privoxy, which comes bundled with Tor but
is meant to provide an HTTP proxy for you and your local users to browse
through and is not designed to be offered as a public service.  If you don't
use Privoxy, would you mind shutting it down?  Or if you do, can you move it
to a different port and/or only allow your own IPs to connect to it?

I'd be happy to provide more information or help you with the configuration
changes if I can.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit relay operators: a call for packets on port 8118

[Aaron Hopkins]

On Mon, 22 Jul 2013, Zack Weinberg wrote:


The CMU Tor exit is seeing about 66 packets/second worth of this
(1 packets, 1151 unique IPs in 149.5 seconds).  I don't have time
to dig any deeper right now, but on the theory that it's a botnet
doing click fraud, I'll pass this along to our cybercrime people.


If this clickfraud bot consumes a thread per connection, it may be possible
to overwhelm its available resources by taking as long as possible to answer
its requests, known as a tarpit or teergrube.

The kernel-based tarpit I wrote years ago (ipt_TARPIT) would only hold these
for a few minutes, so I experimented with getting NginX to reply as slowly
as possible using its rate-limiting, and was able to capture and hold open
105,000 connections to port 8118 from 1500 different IPs.  However, NginX
has a lower bound of one byte per second out of the box, which with TCP
packet overhead consumed more bandwidth than I was willing to offer.

I then wrote a simple Go-based HTTP tarpit, which seems to also be effective
at capturing a bunch of connections; I'm back up to to 22,000 and very
slowly rising.

If anyone else feels like playing with this, feel free to grab
http://www.die.net/tools/http-tarpit/http-tarpit.go and install a Go
compiler from http://golang.org/doc/install.  Build with "go build
http-tarpit.go" and then run "./http-tarpit" as a non-root user.

Be careful if you are tight on RAM; it seems to eat a few hundred megs per
10,000 concurrent connections.  I haven't tried to optimize this at all.

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

Re: [tor-relays] Exit relay operators: a call for packets on port 8118

[Aaron Hopkins]

On Sun, 21 Jul 2013, rotpoison throngnet wrote:


I am hoping that some other exit relay operators can sniff for packets to
destination port 8118


I set up a copy of nginx returning 404s on that port.  After a few thousand
requests, here are the hostnames it is trying to hit:

   4655 ib.adnxs.com
   2193 ad.globe7.com
   1705 ads.creafi-online-media.com
   1149 ad.tagjunction.com
767 ad.yieldmanager.com
259 an.z5x.net
184 ad.z5x.net
123 ad.xertive.com
115 ib.reachjunction.com
 80 tags1.z5x.net
 72 ad.bharatstudent.com
 71 ad.reduxmedia.com
 23 ad.smxchange.com
 18 opt.cdxndirectopt.com
 10 www.xtendadvert.com

It might be worth digging up the security contact for at least the top few
of those and give them a heads up.

And the /24s that have sent at least 100 requests (of 811 unique IPs from 122
/24s):

   1182 23.19.54.0/24
878 173.234.116.0/24
645 208.115.124.0/24
639 173.208.16.0/24
585 23.19.130.0/24
398 64.120.5.0/24
397 64.31.43.0/24
389 64.31.38.0/24
376 64.31.63.0/24
369 173.234.41.0/24
362 108.62.236.0/24
351 23.19.107.0/24
328 173.234.33.0/24
319 64.31.39.0/24
291 108.62.192.0/24
280 108.62.5.0/24
272 173.208.83.0/24
262 208.115.245.0/24
238 69.162.66.0/24
237 70.32.43.0/24
229 216.245.219.0/24
223 64.31.52.0/24
191 64.120.77.0/24
184 173.234.42.0/24
180 64.120.60.0/24
172 63.143.53.0/24
172 23.19.76.0/24
172 23.19.35.0/24
172 173.234.188.0/24
163 173.208.85.0/24
159 208.115.200.0/24
150 173.234.224.0/24
149 173.234.247.0/24
147 64.120.58.0/24
143 74.63.232.0/24
143 74.63.192.0/24
137 108.171.248.0/24
132 64.31.62.0/24
120 108.62.40.0/24
116 64.31.48.0/24
114 173.234.153.0/24
113 74.63.255.0/24
113 108.177.183.0/24
112 69.162.75.0/24
108 208.115.246.0/24
103 74.63.199.0/24
100 63.143.59.0/24

These are very unlikely to have been spoofed, as they were from completed 
TCP connections.


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

Re: [tor-relays] Summary of v0.2.3.x --> v0.2.4.x changes?

[Aaron Hopkins]

On Wed, 3 Jul 2013, Steve Snyder wrote:


Now that Tor v0.2.4.x has reached Release Candidate status, could someone
please inform those who haven't been following the development process
what is new?


https://gitweb.torproject.org/tor.git/blob/tor-0.2.4.15-rc:/ChangeLog has a
bunch of detail.  Look for "Major features".

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

[tor-relays] rpm init script not setting ulimit properly

[Aaron Hopkins]

I noticed my exit node (tordienet) hovering around 1024 connections open,
and checked /proc//limits (available on newer kernels) and noticed that
the filedescriptor ulimit was at the default 1024, which is likely not a
great plan.

I'm using the stock /etc/init.d/tor startup script that came in the
tor-0.2.3.12.alpha-tor.0.rh5_7 RPM offered by the YUM repo
http://deb.torproject.org/torproject.org/rpm/centos5-experimental.  It
attempts to set ulimit, but at least at startup on my Centos 5.8 openvz
container, there's a soft limit set at 1024 filedescriptors, which requires
the -S flag to ulimit to override.

I changed line 87 of /etc/init.d/tor to:

if ulimit -SHn "$MAX_FILEDESCRIPTORS" ; then

And /proc//limits shows tor running with the appropriate limits now.
Unfortunately, this is likely to get reverted with the next package update.

Is anyone else using the stock RPMs seeing the same behavior?

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