Re: [tor-relays] TCP: drop open request

[mett]

On Fri, 25 Oct 2013 01:13:57 -0400
grarpamp  wrote:

> On Fri, Oct 25, 2013 at 12:10 AM, Roger Dingledine 
> wrote:
> > On Fri, Oct 25, 2013 at 12:43:42PM +0900, mett wrote:
> >> Since yesterday, the kern.log of the relay I'm running is flooded
> >> with "TCP: drop open request from".
> >>
> >> I first thought it was a kind of DDOS on our servers but it seems
> >> to be related to Tor (When I stop Tor, kernel doesn't
> >> complain anymore).
> >
> > if you're in BSD-land.
> 
> It's a Linux message. Feed it to a search engine and you'll find
> several things to try depending on what the cause is. It shuts
> off either because Tor is attracting the syn's or the overall count
> is lower with Tor off, you'll have to tcpdump to see. Look into
> syn cookies, packet filter rules, and stack tuning.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Thanks a lot for both answers.

Actually, I recently changed my IP from dynamic to static(a week ago),
and at the same time I changed the settings regarding syn cookies and
spoofed IP's source address verification, so it might have been related.

I'll definitely tcdump my connection to check deeper.

By the way, the system is debian-squeeze on a P4(linux kernel 2.6
serie, 2.4CPU for 512RAM), that I use as a multipurpose router/server.



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

Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedownnotice.

[krishna e bera]

On 13-10-25 07:08 AM, t...@t-3.net wrote:
> ExitPolicy accept *:1723  # PPTP

How are you getting PPTP to work over Tor?  The ISP-supplied modems i've
seen won't pass IP protocol 47 (GRE) packets without putting the target
machine in a DMZ.

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

Re: [tor-relays] Thanks for the advice on handling DMCA complaints.

[Roger Dingledine]

On Fri, Oct 25, 2013 at 11:03:27AM -0400, Christopher Jones wrote:
> I just wanted to thank the list members for giving me some great advice
>on working with my ISP to deal with the DMCA nastygrams. I restricted
>my exit policy to allow most legitimate TCP services and block the rest,
>which should hopefully disincentivize those damn P2P users from picking
>my relay as an exit in most cases.

If you want to go even more conservative, you could allow just 80 and 443.
It would still be useful to many people, and be even less likely to draw
dmca complaints. Something to consider for the future if you need another
step in the negotiation.

> Does the Tor project run a database to track abuse complaints? Could
>be useful in terms of uncovering who the largest pains in the ass are
>(mine was from Irdeto on behalf on NBC Universal), as well as organizing
>targeted campaigns to put pressure on companies like Irdeto to at least
>perform some due diligence and not send out DMCA originating from exit
>relays. If not, maybe I?ll start working on a project to do so if there
>isn?t something else like it elsewhere.

Lunar's pointer to Chilling Effects is a good one.

But see also this mail from the distant past:
https://lists.torproject.org/pipermail/tor-talk/2005-October/016301.html

You see, if somebody sends you a DMCA takedown knowing that it doesn't
apply to you, then *they're* breaking the law. So in theory you could
notify them that you've got safe harbor under DMCA 512(a) and would
they kindly stop harrassing you, and then when they send the next letter
you can countersue. Somebody should do this someday, but it will be an
involved and messy process. On the plus side, some large universities
have successfully used this approach (or more precisely, the threat of
using it) to stop the bigger DMCA bullies from wasting their time. On
the minus side, you as a customer of your ISP don't get to make this
decision, at least not by yourself, because your main problem is the
policy of your ISP, not any actual laws.

> One more question and I?ll probably feel stupid after reading the
>answers, but does ?RelayBandwidthRate? apply separately to rx and tx
>rates or the combined throughput of them both? The server I run has an
>unmetered 100Mb/s connection. I?ve got RelayBandwidthRate set to 5MB and
>RelayBandwidthBurst set to 10MB. 12.5MB/s being the theoretical max,
>if I bumped up my bandwidth rate to, say, 8, would my relay overload
>the NIC or would it continue to behave?

Tor counts bytes separately in each direction. So 5Mbytes means 5mbytes
reading and 5mbytes writing. So you are currently limiting your relay
to a long-term average of 40mbps.

> At last check, I had 1140 TCP connections according to lsof and vnstat
>is showing throughputs of 13-18Mbit/s rx and 14-19Mbit/s tx. Tor CPU
>usage is about 22-27% according to top.
> 
> Does this look reasonable or should I tweak some things like max connections?

There isn't any functionality currently to limit how many connections
your relay will use/accept. You need to be able to have a connection
open to every other relay, and to the exit destinations that users ask
for (if your exit policy allows it), and to clients if they pick you for
their first hop. Refusing to do any of those connections degrades service
(and in the relay-to-relay connection case, it potentially messes with
anonymity in complex ways too, since the Tor network is no longer a
clique topology).

Fortunately, sockets are basically free on a real OS. The main challenge
comes up in cheap VPS systems where they artificially limit system
resources to make it hard for you to do anything with your VPS.

--Roger

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

Re: [tor-relays] [tor-talk] A new check

[grarpamp]

>> > > We're considering launching a new check,
>> > >
>> > > It'd be appreciated if you could take a moment to look for false 
>> > > negatives,
>> > > and let us know.
>> >
>> > I found 15 relays where check2 told me that I'm not using Tor.
>>
>> Very good idea! :) Did you also run the same test against
>> check.torproject.org?

Keep in mind that while it may be frustrating to some users config
tests to find that they are temporarily using a false negative exit...
this 'multihoming' could, and should in fact, be considered a feature
since it keeps some exits out of the reach of anti-tor blocklists
that simply parse all the IP's out of the descriptor set. Similar to
how obfs and other design features keep Tor out of the reach of
anti-tor entities, making an anti to do a little work to be an anti is
a good thing. Thus having a good number of false negatives around
can allow you to reach places you couldn't otherwise reach due
to that type of blocking. That may cause philosophical stress to some
places that indiscriminantly [1] block Tor IP's by default, but also keep
in mind that Tor is dual use and such a policy is rather blind to that by
definition... as would be indiscriminantly blocking all coffee shop IP's
by default. So if the point of 'looking for false negatives' is to do something,
like attempt to convince the operators to not multihome... the better thing
to do would be to add regular false negative tests to the backend of the
check service so that these exits come up positive therein.

[1] Within a day ago I posted a link to a slashdot discussion of
one particular instance of this.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Thanks for the advice on handling DMCA complaints.

[Lunar]

Christopher Jones:
> Does the Tor project run a database to track abuse complaints? Could
> be useful in terms of uncovering who the largest pains in the ass are
> (mine was from Irdeto on behalf on NBC Universal), as well as
> organizing targeted campaigns to put pressure on companies like Irdeto
> to at least perform some due diligence and not send out DMCA
> originating from exit relays. If not, maybe I’ll start working on a
> project to do so if there isn’t something else like it elsewhere.

Not the Tor project itself, but have a loot at Chilling Effects:
. It was founded by Wendy Seltzer who
is also on the board of directors of The Tor Project. Chilling Effects
would probably welcome your help. :)

-- 
Lunar 


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

[tor-relays] Thanks for the advice on handling DMCA complaints.

[Christopher Jones]

Hey all,

I just wanted to thank the list members for giving me some great advice on 
working with my ISP to deal with the DMCA nastygrams. I restricted my exit 
policy to allow most legitimate TCP services and block the rest, which should 
hopefully disincentivize those damn P2P users from picking my relay as an exit 
in most cases. 

Does the Tor project run a database to track abuse complaints? Could be useful 
in terms of uncovering who the largest pains in the ass are (mine was from 
Irdeto on behalf on NBC Universal), as well as organizing targeted campaigns to 
put pressure on companies like Irdeto to at least perform some due diligence 
and not send out DMCA originating from exit relays. If not, maybe I’ll start 
working on a project to do so if there isn’t something else like it elsewhere.

On another note, I discovered I prefer running Tor on FreeBSD over Linux. Ran 
CentOS for a bit, but somehow encrypting /tmp blew it up and the NOC had to 
re-install the OS. I went with FreeBSD instead and dig it immensely. Pf is much 
less of a headache than IPTables — I actually got port forwarding from 80 to 
9091 and 43 to 9090 working. Administration is more straightforward. I like the 
clear separation of the base system from additional software added from ports. 
Compiling ports, while more time consuming, is a delight compared to some of 
the binary package management issues I’ve had in the past with Linux. FreeBSD 
also appears to manage memory more efficiently. I run Linux as a desktop OS, 
but for a server OS, FreeBSD has won me over with its simplicity, less 
convoluted security (no SELinux — yes I know you can turn it off, but I’m the 
masochist who leaves it on), better support for chroot jails. Just my opinion.

One more question and I’ll probably feel stupid after reading the answers, but 
does “RelayBandwidthRate” apply separately to rx and tx rates or the combined 
throughput of them both? The server I run has an unmetered 100Mb/s connection. 
I’ve got RelayBandwidthRate set to 5MB and RelayBandwidthBurst set to 10MB. 
12.5MB/s being the theoretical max, if I bumped up my bandwidth rate to, say, 
8, would my relay overload the NIC or would it continue to behave?

My server specs are as follows:

FreeBSD 9.2
Dual Core Atom D2500
4GB RAM
2TB SATA drive (encrypted swap and /tmp)
100Mbit unmetered traffic
5 usable IPv4 addresses

At last check, I had 1140 TCP connections according to lsof and vnstat is 
showing throughputs of 13-18Mbit/s rx and 14-19Mbit/s tx. Tor CPU usage is 
about 22-27% according to top.

Does this look reasonable or should I tweak some things like max connections?

Thanks,
Chris

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

Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedownnotice.

[tor]

Reply to the email, say that you found a misconfiguration in your Tor
daemon which could have accounted for this problem and you've repaired
it, and hopefully this problem is resolved for the future.

Put the below as your exit policy in torrc, and I'd stop/start the
service to be sure it grabbed it.

Using the below exit policy, we've had our exit node running for a
couple months or so doing pretty good bandwidth, and not had a single
warez-related complaint. Seen some complaints about SQL injection
attacks but perhaps those will annoy your ISP less.

ExitPolicy accept *:20-23 # FTP, SSH, telnet
ExitPolicy accept *:43# WHOIS
ExitPolicy accept *:53# DNS
ExitPolicy accept *:79-81 # finger, HTTP
ExitPolicy accept *:88# kerberos
ExitPolicy accept *:110   # POP3
ExitPolicy accept *:143   # IMAP
ExitPolicy accept *:194   # IRC
ExitPolicy accept *:220   # IMAP3
ExitPolicy accept *:389   # LDAP
ExitPolicy accept *:443   # HTTPS
ExitPolicy accept *:464   # kpasswd
ExitPolicy accept *:531   # IRC/AIM
ExitPolicy accept *:543-544   # Kerberos
ExitPolicy accept *:554   # RTSP
ExitPolicy accept *:563   # NNTP over SSL
ExitPolicy accept *:636   # LDAP over SSL
ExitPolicy accept *:706   # SILC
ExitPolicy accept *:749   # kerberos
ExitPolicy accept *:873   # rsync
ExitPolicy accept *:902-904   # VMware
ExitPolicy accept *:981   # Remote HTTPS management for firewall
ExitPolicy accept *:989-995   # FTP over SSL, Netnews etc
ExitPolicy accept *:1194  # OpenVPN
ExitPolicy accept *:1220  # QT Server Admin
ExitPolicy accept *:1293  # PKT-KRB-IPSec
ExitPolicy accept *:1500  # VLSI License Manager
ExitPolicy accept *:1533  # Sametime
ExitPolicy accept *:1677  # GroupWise
ExitPolicy accept *:1723  # PPTP
ExitPolicy accept *:1755  # RTSP
ExitPolicy accept *:1863  # MSNP
ExitPolicy accept *:2082  # Infowave Mobility Server
ExitPolicy accept *:2083  # Secure Radius Service (radsec)
ExitPolicy accept *:2086-2087 # GNUnet, ELI
ExitPolicy accept *:2095-2096 # NBX
ExitPolicy accept *:2102-2104 # Zephyr
ExitPolicy accept *:3128  # SQUID
ExitPolicy accept *:3389  # MS WBT
ExitPolicy accept *:3690  # SVN
ExitPolicy accept *:4321  # RWHOIS
ExitPolicy accept *:4643  # Virtuozzo
ExitPolicy accept *:5050  # MMCC
ExitPolicy accept *:5190  # ICQ
ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL
ExitPolicy accept *:5228  # Android Market
ExitPolicy accept *:5900  # VNC
ExitPolicy accept *:6660-6669 # IRC
ExitPolicy accept *:6679  # IRC SSL
ExitPolicy accept *:6697  # IRC SSL
ExitPolicy accept *:8000  # iRDMI
ExitPolicy accept *:8008  # HTTP alternate
ExitPolicy accept *:8074  # Gadu-Gadu
ExitPolicy accept *:8080  # HTTP Proxies
ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan 
HTTP

ExitPolicy accept *:8332-8333 # BitCoin
ExitPolicy accept *:8443  # PCsync HTTPS
ExitPolicy accept *:  # HTTP Proxies, NewsEDGE
ExitPolicy accept *:9418  # git
ExitPolicy accept *:  # distinct
ExitPolicy accept *:1 # Network Data Management Protocol
ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol)
ExitPolicy accept *:12350 # Skype
ExitPolicy accept *:19294 # Google Voice TCP
ExitPolicy accept *:19638 # Ensim control panel
ExitPolicy accept *:23456 # Skype
ExitPolicy accept *:33033 # Skype
ExitPolicy reject *:*




On Thursday 24/10/2013 at 9:11 pm, Christopher Jones  wrote:


I’ve been running an exit relay for about 3 days and, sure enough, 
some BitTorrent bugger caused sh3lls.net to send me a DMCA nastygram:




We have got the following complain, please remove all illegal torrents 
immediately from your server:


Evidentiary Information
Title: Suits (TV)
Infringement Source: BitTorrent
Initial Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Recent 
Infringement Timestamp: 17 Oct 2013 22:06:17 GMT Infringing Filename: 
Suits Season 3 Episode 6 (The Other Time) (HDTV x264)-ASAP (1GBps 
SeedBox).mp4 URL if applicable:

Infringing File size: 364405400
Infringers IP Address: 64.32.14.34
Bay ID: 7fbb4256bfca558d5a809b9f6536b5fd5e4e782d|364405400
Port ID: 33788


I followed through with the templates provided by the Tor Project as a 
response to the DMCA takedown notification. A day later, the ISP sent 
me this:




Dear Christopher
Whether you run Tor or not, we even told you in past, it's your 
responsibility to stop all abuse
If Tor is causing it, stop the program Tor on your server, if we get 
another complain we will have to suspend/terminate your services


tor always always gets lots and lots of abuse and complains

Update us within 24 hours

Thanks


I was never provided with the full text of the original DMCA 
complaint, so I was unable to respond. Furthermore, I was never 
“even told…in the past” that I had to stop all abuse caused by 
Tor. Tor is not singled out in the ToS 

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

[Das, Anupam]

So we have received some questions about running our traceroute measurements. 
Let me answer some of the questions:

--
From: Aaron Hopkins [li...@die.net]

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

We are not looking for "chokepoints" exactly. We are interested in knowing as 
much as possible about where the traffic goes and who can see it. 

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

Our BGP prefixes are derived from RouteViews BGP tables. There is no guarantee 
that these are the prefixes used by all Internet routers, much less that 
routing is consistent over all IPs in the prefix.
In addition, these prefixes change over time. Doing all /24 prefixes would 
enable us to study finer-grained routing behavior.

>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

We have randomized the prefix list. And will soon randomize the /24 list too.

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

We tested running 128 parallel traceroute. We found the CPU (<5%) and RAM 
(<0.2% for 8GB RAM) requirements really small .
We can also choose how many traceroutes you want to run using the following 
command-

PARALLEL=64 ./traceroutes.sh &
if you want to run 64 traceroutes in parallel

If you are using scamper (which we encourage you to do) you can tell the script 
how many packets-per-second you want using the following command-

PPS=800 ./traceroutes.sh &
where 1<=PPS<=1000


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

Running from a machine on the same network is absolutely just as good as long 
as they definitely send the same traffic through the same Internet gateways.


---
From: Geoff Down geoffdown at fastmail.net 

>Your README should probably explicitly say that you need to run
>sudo chmod 04555 /path/to/scamper
>after installing scamper or it won't work.

Yes we have mentioned that on the README now.


From: Jesse Victors jvictors at jessevictors.com 

>How much bandwidth will this be taking up, and roughly how much will be
>uploaded/downloaded? I've cloned the repo, but I'm nervous about running
>this if it's going to be a significant bandwidth hog for a whole week.
>As Aaron said in Issue 39, it looks like it's going to be a lot of IPs
>and a large amount of packets. Also, ISPs may not take kindly to all
>these scans. What's the word on that? Has anyone run this tool, and
>what's their opinion? I'd be happy to help, but I'd like to know the
>full details of the various resources this tool will be consuming.

We have provided some resource requirements at the end of the README file. I'll 
just summarize all of them here-

1. Upload: The script generate less than 500MB of total data. By default the 
files are erased once
they are uploaded, but you can choose not to erase any data.


2. Bandwidth: If scamper used then with all the default setting it would consume
at most 0.5 megabit of bandwidth. However, you can choose to reduce the 
consumption by changing

the PPS (packet-per-second) parameter (1<=PPS<=1000) using the following command

PPS=800 ./traceroutes.sh &

With reasonable bandwidth line (>100Mbps) this form of traceroutes shouldn't be 
much of a load to any ISP.

3. RAM and CPU usage: We have tested out the script on multiple machines. We 
found the following resource usage

RAM <0.2% (for 8GB RAM) and CPU < 5%.

Hope this gives you some idea about the resource requirements.

Thanks

Anupam Das

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