Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Sec INT 
Hi

Not sure if my reply worked yesterday so thanks for this - adding 'port' worked 
and Ive now got two fully working exits ;-) thanks for the help 

Cheers Mark 


> On 29 Nov 2016, at 10:32, Peter Palfrader  wrote:
> 
>> On Tue, 29 Nov 2016, Sec INT wrote:
>>> On Tue, Nov 29, 2016 at 10:14 AM, Peter Palfrader  
>>> wrote:
 On Tue, 29 Nov 2016, Sec INT wrote:
 Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown option 
 'DirFrontPage'.  Failing.
>>> What is DirFrontPage supposed to be?  The manpage only mentions a
>>> DirPortFrontPage.
> 
>> Its on a number of setup guides for an exit relay whereby if someone looks
>> up your ip and port 80 they will see this webpage - its designed to reduce
>> DMCA notices and accusations against someone running an exit - I've
>> attached the actual page
>> 
>> https://blog.torproject.org/running-exit-node
>> https://tor-relay.co/
>> 
>> Perhaps this option no longer exists as I use the most up to date versions
>> of tor (0.2.8.9) at the moment - I run on ports 443 and 80
> 
> Please read what I wrote, and read your error message.
> 
> -- 
>|  .''`.   ** Debian **
>  Peter Palfrader   | : :' :  The  universal
> https://www.palfrader.org/ | `. `'  Operating System
>|   `-https://www.debian.org/
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] is it possible to relay using ipv6?

2016-11-29 Thread teor 

> On 30 Nov. 2016, at 02:18, Zack Weinberg  wrote:
> 
> On Sun, Nov 27, 2016 at 6:01 PM, teor  wrote:
>> 
>> If IPv6 penetration among Tor relay ISPs/ASs is as high as you say, why
>> do only:
>> 
>> 7.6% (541/7145) of relays have an IPv6 OR address
>> 17.3% (7972687/45960632) of relay bandwidth has an IPv6 OR address
>> 
>> With IPv6 relay bandwidth this low, we can't even have clients try IPv6
>> by default - there are too few relays to meet Tor's existing 60% path
>> threshold in get_frac_paths_needed_for_circs().
> 
> I want to add something to these figures: (modified code at end)
> 
> 7.5% (535/7171) of relays have an IPv6 OR address
> 16.8% (7800233/46493235) of relay bandwidth has an IPv6 OR address
> 
> 16.9% (343/2034) of guard relays have an IPv6 OR address
> 23.3% (7364620/31664680) of guard relay bandwidth has an IPv6 OR address
> 
> 9.8% (89/908) of exit relays have an IPv6 OR address
> 18.2% (1954308/10754720) of exit relay bandwidth has an IPv6 OR address

Thanks!

> This is better than I expected -- I thought IPv6-capable exit relays
> in particular would be few and far between.

IPv6 tends to experience less network filtering at both the client to
tor and Exit to site stages. It would be great for Tor users if Tor
used it more.

And if only 18.2% of exit relay bandwidth has an IPv6 address, and
clients try 3 exits before giving up, this means there's still a 45.4%
chance that an IPv6-only site accesses via DNS will fail.

(IPv6 addresses are fine - the client chooses an IPv6-capable relay.)

> Still, I worry that we
> might hit a ceiling on IPv6 adoption by exits, because exit-friendly
> connectivity tends to come from places where keeping up with the
> bleeding edge in network gear isn't the top priority, like libraries
> and universities.  Despite how many network researchers we have here,
> CMU (and therefore my exit node)

Exit nodes are chosen at random - they certainly aren't chosen by
proximity to the client.

> doesn't have IPv6; campus IT tells me
> that it's on their list but there are several higher-priority hardware
> upgrades that need to happen first, and the ETA has been "three to
> five years from now" for my entire time here.

That's unfortunate. It's also hard to get IPv6 when choosing between
datacenter providers - there are many criteria, such as price and
bandwidth (and location, and diversity) that matter, and it's hard to
find somewhere that satisfies all of them.

> zw
> 
> #! /usr/bin/python3
> import stem.descriptor.remote
> from stem import Flag
> 
> consensus = stem.descriptor.remote.DescriptorDownloader().get_consensus()
> total_count = total_bw = 0
> total_guard_count = total_guard_bw = 0
> total_exit_count = total_exit_bw = 0
> ipv6_count = ipv6_bw = 0
> ipv6_guard_count = ipv6_guard_bw = 0
> ipv6_exit_count = ipv6_exit_bw = 0
> 
> for relay in consensus:
>is_guard = Flag.GUARD in relay.flags
>is_exit  = Flag.EXIT in relay.flags
>for address in relay.or_addresses:
>if address[2]: # is_ipv6
>has_ipv6 = True
>break
>else:
>has_ipv6 = False
> 
>if has_ipv6:
>ipv6_count += 1
>ipv6_bw += relay.bandwidth

Better do this here, too:

>   # Relays with both EXIT and GUARD are, IIUC, used only as exits.

(And yes, this is true, as long as Exits are scarce.)

>if is_guard:
>ipv6_guard_count += 1
>ipv6_guard_bw += relay.bandwidth
>if is_exit:
>ipv6_exit_count += 1
>ipv6_exit_bw += relay.bandwidth
> 
>total_count += 1
>total_bw += relay.bandwidth
>if is_exit:
>total_exit_count += 1
>total_exit_bw += relay.bandwidth
># Relays with both EXIT and GUARD are, IIUC, used only as exits.
>elif is_guard:
>total_guard_count += 1
>total_guard_bw += relay.bandwidth
> 
> print("%.1f%% (%d/%d) of relays have an IPv6 OR address" %
>  (ipv6_count*100.0/total_count, ipv6_count, total_count))
> print("%.1f%% (%d/%d) of relay bandwidth has an IPv6 OR address" %
>  (ipv6_bw*100.0/total_bw, ipv6_bw, total_bw))
> print()
> print("%.1f%% (%d/%d) of guard relays have an IPv6 OR address" %
>  (ipv6_guard_count*100.0/total_guard_count,
>   ipv6_guard_count, total_guard_count))
> print("%.1f%% (%d/%d) of guard relay bandwidth has an IPv6 OR address" %
>  (ipv6_guard_bw*100.0/total_guard_bw, ipv6_guard_bw, total_guard_bw))
> print()
> print("%.1f%% (%d/%d) of exit relays have an IPv6 OR address" %
>  (ipv6_exit_count*100.0/total_exit_count,
>   ipv6_exit_count, total_exit_count))
> print("%.1f%% (%d/%d) of exit relay bandwidth has an IPv6 OR address" %
>  (ipv6_exit_bw*100.0/total_exit_bw, ipv6_exit_bw, total_exit_bw))

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

[tor-relays] re

2016-11-29 Thread dark side 
re
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] (no subject)

2016-11-29 Thread Diarmaid McManus 
Bridges can be gotten over email, also, at brid...@bridges.torproject.org
with "get bridges" in the body.

On 29 November 2016 at 19:36, fnordomat  wrote:

> you can get them from https://bridges.torproject.org
>
> dark side:
> > i need some relays bridges to use
> > ___
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] i need some bridges

2016-11-29 Thread dark side 

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

Re: [tor-relays] Blocking PSN

2016-11-29 Thread pa011 
You can contact them on the given snei-noc-ab...@am.sony.com and they will give 
you a list of attacked IPs.

Paul

Am 29.11.2016 um 14:48 schrieb SuperSluether:
> I keep getting Account Takeover Attempt abuses on my Tor exit, and I'm not 
> sure how to handle them:
> 
> It is most likely the attack traffic is directed at one of the following 
> endpoints:
> 
> account.sonyentertainmentnetwork.com
> auth.np.ac.playstation.net
> auth.api.sonyentertainmentnetwork.com
> auth.api.np.ac.playstation.net
> 
> These endpoints on our network are resolved by Geo DNS, so the IP addresses 
> they resolve to will depend on the originating IP address.
> 
> The destination port will be TCP 443.
> 
> 
> I used 'dig' and 'ping' to see what IP address the 4 endpoints resolved as, 
> and blocked the resulting addresses, but I'm still getting the abuse. The 
> Whois records show Sony and PSN owning 63.x.x.x, 64.x.x.x, 68.x.x.x, and 
> 108.x.x.x addresses, but the websites above resolve to 23.x.x.x, so either 
> the lists are incomplete or I'm doing something wrong.
> 
> Any ideas?
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] is it possible to relay using ipv6?

2016-11-29 Thread Zack Weinberg 
On Sun, Nov 27, 2016 at 6:01 PM, teor  wrote:
>
> If IPv6 penetration among Tor relay ISPs/ASs is as high as you say, why
> do only:
>
> 7.6% (541/7145) of relays have an IPv6 OR address
> 17.3% (7972687/45960632) of relay bandwidth has an IPv6 OR address
>
> With IPv6 relay bandwidth this low, we can't even have clients try IPv6
> by default - there are too few relays to meet Tor's existing 60% path
> threshold in get_frac_paths_needed_for_circs().

I want to add something to these figures: (modified code at end)

7.5% (535/7171) of relays have an IPv6 OR address
16.8% (7800233/46493235) of relay bandwidth has an IPv6 OR address

16.9% (343/2034) of guard relays have an IPv6 OR address
23.3% (7364620/31664680) of guard relay bandwidth has an IPv6 OR address

9.8% (89/908) of exit relays have an IPv6 OR address
18.2% (1954308/10754720) of exit relay bandwidth has an IPv6 OR address

This is better than I expected -- I thought IPv6-capable exit relays
in particular would be few and far between.  Still, I worry that we
might hit a ceiling on IPv6 adoption by exits, because exit-friendly
connectivity tends to come from places where keeping up with the
bleeding edge in network gear isn't the top priority, like libraries
and universities.  Despite how many network researchers we have here,
CMU (and therefore my exit node) doesn't have IPv6; campus IT tells me
that it's on their list but there are several higher-priority hardware
upgrades that need to happen first, and the ETA has been "three to
five years from now" for my entire time here.

zw

#! /usr/bin/python3
import stem.descriptor.remote
from stem import Flag

consensus = stem.descriptor.remote.DescriptorDownloader().get_consensus()
total_count = total_bw = 0
total_guard_count = total_guard_bw = 0
total_exit_count = total_exit_bw = 0
ipv6_count = ipv6_bw = 0
ipv6_guard_count = ipv6_guard_bw = 0
ipv6_exit_count = ipv6_exit_bw = 0

for relay in consensus:
is_guard = Flag.GUARD in relay.flags
is_exit  = Flag.EXIT in relay.flags
for address in relay.or_addresses:
if address[2]: # is_ipv6
has_ipv6 = True
break
else:
has_ipv6 = False

if has_ipv6:
ipv6_count += 1
ipv6_bw += relay.bandwidth
if is_guard:
ipv6_guard_count += 1
ipv6_guard_bw += relay.bandwidth
if is_exit:
ipv6_exit_count += 1
ipv6_exit_bw += relay.bandwidth

total_count += 1
total_bw += relay.bandwidth
if is_exit:
total_exit_count += 1
total_exit_bw += relay.bandwidth
# Relays with both EXIT and GUARD are, IIUC, used only as exits.
elif is_guard:
total_guard_count += 1
total_guard_bw += relay.bandwidth

print("%.1f%% (%d/%d) of relays have an IPv6 OR address" %
  (ipv6_count*100.0/total_count, ipv6_count, total_count))
print("%.1f%% (%d/%d) of relay bandwidth has an IPv6 OR address" %
  (ipv6_bw*100.0/total_bw, ipv6_bw, total_bw))
print()
print("%.1f%% (%d/%d) of guard relays have an IPv6 OR address" %
  (ipv6_guard_count*100.0/total_guard_count,
   ipv6_guard_count, total_guard_count))
print("%.1f%% (%d/%d) of guard relay bandwidth has an IPv6 OR address" %
  (ipv6_guard_bw*100.0/total_guard_bw, ipv6_guard_bw, total_guard_bw))
print()
print("%.1f%% (%d/%d) of exit relays have an IPv6 OR address" %
  (ipv6_exit_count*100.0/total_exit_count,
   ipv6_exit_count, total_exit_count))
print("%.1f%% (%d/%d) of exit relay bandwidth has an IPv6 OR address" %
  (ipv6_exit_bw*100.0/total_exit_bw, ipv6_exit_bw, total_exit_bw))
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Blocking PSN

2016-11-29 Thread SuperSluether 
I keep getting Account Takeover Attempt abuses on my Tor exit, and I'm 
not sure how to handle them:


It is most likely the attack traffic is directed at one of the following 
endpoints:

account.sonyentertainmentnetwork.com
auth.np.ac.playstation.net
auth.api.sonyentertainmentnetwork.com
auth.api.np.ac.playstation.net

These endpoints on our network are resolved by Geo DNS, so the IP addresses 
they resolve to will depend on the originating IP address.

The destination port will be TCP 443.


I used 'dig' and 'ping' to see what IP address the 4 endpoints resolved 
as, and blocked the resulting addresses, but I'm still getting the 
abuse. The Whois records show Sony and PSN owning 63.x.x.x, 64.x.x.x, 
68.x.x.x, and 108.x.x.x addresses, but the websites above resolve to 
23.x.x.x, so either the lists are incomplete or I'm doing something wrong.


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

Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Sec INT 
Got it - sorry was distracted by Nagios install ;-)

all working - I've added a comment to the site I was using

cheers

Mark

On Tue, Nov 29, 2016 at 10:32 AM, Peter Palfrader 
wrote:

> On Tue, 29 Nov 2016, Sec INT wrote:
> > On Tue, Nov 29, 2016 at 10:14 AM, Peter Palfrader 
> wrote:
> > > On Tue, 29 Nov 2016, Sec INT wrote:
> > > > Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown
> option 'DirFrontPage'.  Failing.
> > > What is DirFrontPage supposed to be?  The manpage only mentions a
> > > DirPortFrontPage.
>
> > Its on a number of setup guides for an exit relay whereby if someone
> looks
> > up your ip and port 80 they will see this webpage - its designed to
> reduce
> > DMCA notices and accusations against someone running an exit - I've
> > attached the actual page
> >
> > https://blog.torproject.org/running-exit-node
> > https://tor-relay.co/
> >
> > Perhaps this option no longer exists as I use the most up to date
> versions
> > of tor (0.2.8.9) at the moment - I run on ports 443 and 80
>
> Please read what I wrote, and read your error message.
>
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] is it possible to relay using ipv6?

2016-11-29 Thread teor 

> On 28 Nov. 2016, at 10:01, teor  wrote:
> 
>>> All this new fancy ISPs that have FTTH and
>>>   give you 500 MBit/s symmetric internet access have Carrier grade
>>>   NAT because they were late to the Party and don't get IPv4 from
>>>   the LIRs.
>>>   You can't run there a relay because of the stupid you need a
>>>   public accessible IPv4 address shit.
> 
> You can run a high-bandwidth IPv6-only bridge relay.
> This really helps censored users on IPv6-only networks (or on networks
> where IPv6 is less filtered).

I'm sorry, I was wrong, IPv6-only bridge relays don't work for clients:
https://trac.torproject.org/projects/tor/ticket/4847

I'd happily review a patch for this issue.

And just as happily review a chutney integration test for an IPv6-only
bridge, to make sure we don't re-introduce the bug.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




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

Re: [tor-relays] is it possible to relay using ipv6?

2016-11-29 Thread teor 

> On 29 Nov. 2016, at 18:44, Roman Mamedov  wrote:
> 
> On Mon, 28 Nov 2016 10:01:03 +1100
> teor  wrote:
> 
>> (I've rearranged your threads for clarity, please bottom-post in future.)
>> 
 On Nov 27, 2016 11:59 AM, "root" > wrote:
 
   It is end 2016 we should change from must have IPv4 to must have
   IPv6 and can have IPv4.

https://trac.torproject.org/projects/tor/ticket/5788

>> 
>> When the proportion of Tor relays with IPv6 is above 60%, dual stack by
>> default on clients is a feasible option.
>> 
>> When the proportion exceeds 85% (the cube root of 60%), a switch may
>> become plausible.
>> 
>> The proportion of Tor relays with IPv6 is currently at 17% of
>> bandwidth.
> 
> Could have been higher, if it weren't so cumbersome to configure.
> 
> If you honestly want Tor IPv6 adoption to go up, you should stop treating it
> as a second-class citizen in Tor, i.e. firstly remove the need to have a
> static literal IPv6 in the config. Not a single other network daemon requires
> that. And many home IPv6 allocations are dynamic, so users with those can't
> feasibly set that up even if they wanted.
> 
> What was it, "it's tricky to autodetect which IPv6 to use"? No it's really
> not. Even starting with a simple "ip route get 2001:db8::", then looking at
> what "src" you get and if it's a proper global one (in 2000::/3),

It might surprise you, but I agree with most of what you've said so far.

In fact, several developers have spent the last few years laying the
groundwork for IPv6 autodetection.

There's already a function in Tor that retrieves a list of local IPv4 and
IPv6 addresses:
https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1773

It's cross-platform, has a fallback strategy to retrieve the default
interface address, and works quite well.

But there's more work to be done:

https://trac.torproject.org/projects/tor/ticket/5940

> and try to
> retrieve something from the Tor project over v6 to confirm that it actually
> works. Done.

If we're talking clients, that's terribly bad for anonymity, because it would
allow the Tor Project to collect the addresses of every IPv6 Tor user.

If we're talking relays, that's terribly bad for reliability, because it
would make the Tor Project (website?) a single point of failure.

Here's how we actually do it for IPv4:

Relays retrieve their directory documents over IPv4, and a directory mirror
tells them their (apparent, public) IPv4 address in the headers.

Here's why that won't work for IPv6:

There are no IPv6 DirPorts. (That is, you can set one up, but no client or
relay will use it, because there is no way for relays to advertise an IPv6
DirPort.)

Here's a solution to that issue:

HTTP headers are also unauthenticated, so we want to switch to using NETINFO
cells to discover IPv4 addresses. When we do this, it will work for IPv6 as
well as IPv4.

Here's an issue caused by headers being unauthenticated:

https://trac.torproject.org/projects/tor/ticket/16205
https://trac.torproject.org/projects/tor/ticket/17605

Here's a general issue with autodetection:

> On 28 Nov. 2016, at 10:01, teor  wrote:

> 
> How do we deal with relays which have an IPv6 address that doesn't
> work?
> * Relays should self-test their IPv6 ORPort, but there's a race
>  condition here:
>  * if relays only publish their IPv6 ORPort after testing it, they
>can flip between having and not having an IPv6 address in their
>descriptor. This is bad for descriptor stability.

https://trac.torproject.org/projects/tor/ticket/13112

We just fixed an issue like this with the IPv4 DirPort reachability
test. I'd rather not re-introduce a similar issue for IPv6 ORPort
reachability:

https://trac.torproject.org/projects/tor/ticket/18050

> * If relays don't self-test their IPv6 ORPort, authorities will exclude
>  them from the consensus if it turns out to be unreachable. This is a
>  more significant issue if Tor autoconfigures IPv6

It can be hard for a relay to self-test its IPv6 ORPort, because it has
to build a path with an IPv6 relay at the next-to-last hop. (When
self-testing, the originating relay connects to its own ORPort via
a few other relays.)

https://trac.torproject.org/projects/tor/ticket/4565

This is doable, but we'd need to write code to make this happen. And
we'd need to test that current tor versions actually use IPv6 when
asked, rather than using an existing IPv4 connection to the same relay.

https://trac.torproject.org/projects/tor/ticket/6939

Another issue with autodetection is which address should be chosen if
there are multiple valid IP addresses. As far as I know, this is much
more common with IPv6 than IPv4. Tor doesn't have code that discovers
the IP address of the default route, instead, we use the OS order.
(Well, most versions do. There was a bug in some recent versions that
reordered addresses from the OS order.)

This

Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Peter Palfrader 
On Tue, 29 Nov 2016, Sec INT wrote:
> On Tue, Nov 29, 2016 at 10:14 AM, Peter Palfrader  
> wrote:
> > On Tue, 29 Nov 2016, Sec INT wrote:
> > > Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown 
> > > option 'DirFrontPage'.  Failing.
> > What is DirFrontPage supposed to be?  The manpage only mentions a
> > DirPortFrontPage.

> Its on a number of setup guides for an exit relay whereby if someone looks
> up your ip and port 80 they will see this webpage - its designed to reduce
> DMCA notices and accusations against someone running an exit - I've
> attached the actual page
> 
> https://blog.torproject.org/running-exit-node
> https://tor-relay.co/
> 
> Perhaps this option no longer exists as I use the most up to date versions
> of tor (0.2.8.9) at the moment - I run on ports 443 and 80

Please read what I wrote, and read your error message.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Sec INT 
Hi

Its on a number of setup guides for an exit relay whereby if someone looks
up your ip and port 80 they will see this webpage - its designed to reduce
DMCA notices and accusations against someone running an exit - I've
attached the actual page

https://blog.torproject.org/running-exit-node
https://tor-relay.co/

Perhaps this option no longer exists as I use the most up to date versions
of tor (0.2.8.9) at the moment - I run on ports 443 and 80

cheers

Mark


On Tue, Nov 29, 2016 at 10:14 AM, Peter Palfrader 
wrote:

> On Tue, 29 Nov 2016, Sec INT wrote:
>
> > Hi
> >
> > Thanks ;-) As for the 'DirFrontPAge' the error is below
> >
> > Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown
> option
> > 'DirFrontPage'.  Failing.
>
> What is DirFrontPage supposed to be?  The manpage only mentions a
> DirPortFrontPage.
>
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
Title: This is a Tor Exit Router






This is a
Tor Exit Router


Most likely you are accessing this website because you had some issue with
the traffic coming from this IP. This router is part of the Tor Anonymity Network, which is
dedicated to providing
privacy to people who need it most: average computer users. This
router IP should be generating no other traffic, unless it has been
compromised.










Tor sees use by many
important segments of the population, including whistle blowers,
journalists, Chinese dissidents skirting the Great Firewall and oppressive
censorship, abuse victims, stalker targets, the US military, and law
enforcement, just to name a few.  While Tor is not designed for malicious
computer users, it is true that they can use the network for malicious ends.
In reality however, the actual amount of abuse is quite low. This
is largely because criminals and hackers have significantly better access to
privacy and anonymity than do the regular users whom they prey upon. Criminals
can and do build,
sell, and trade far larger and more
powerful networks than Tor on a daily basis. Thus, in the mind of this
operator, the social need for easily accessible censorship-resistant private,
anonymous communication trumps the risk of unskilled bad actors, who are
almost always more easily uncovered by traditional police work than by
extensive monitoring and surveillance anyway.


In terms of applicable law, the best way to understand Tor is to consider it a
network of routers operating as common carriers, much like the Internet
backbone. However, unlike the Internet backbone routers, Tor routers
explicitly do not contain identifiable routing information about the source of
a packet, and no single Tor node can determine both the origin and destination
of a given transmission.


As such, there is little the operator of this router can do to help you track
the connection further. This router maintains no logs of any of the Tor
traffic, so there is little that can be done to trace either legitimate or
illegitimate traffic (or to filter one from the other).  Attempts to
seize this router will accomplish nothing.






If you are a representative of a company who feels that this router is being
used to violate the DMCA, please be aware that this machine does not host or
contain any illegal content. Also be aware that network infrastructure
maintainers are not liable for the type of content that passes over their
equipment, in accordance with DMCA
"safe harbor" provisions. In other words, you will have just as much luck
sending a takedown notice to the Internet backbone providers. Please consult
EFF's prepared
response for more information on this matter.

For more information, please consult the following documentation:


Tor Overview
Tor Abuse FAQ
Tor Legal FAQ



That being said, if you still have a complaint about the router,  you may
email the maintainer. If
complaints are related to a particular service that is being abused, I will
consider removing that service from my exit policy, which would prevent my
router from allowing that traffic to exit through it. I can only do this on an
IP+destination port basis, however. Common P2P ports are
already blocked.


You also have the option of blocking this IP address and others on
the Tor network if you so desire. The Tor project provides a web service
to fetch a list of all IP addresses of Tor exit nodes that allow exiting to a
specified IP:port combination, and an official DNSRBL is also available to
determine if a given IP address is actually a Tor exit server. Please
be considerate
when using these options. It would be unfortunate to deny all Tor users access
to your site indefinitely

Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Peter Palfrader 
On Tue, 29 Nov 2016, Sec INT wrote:

> Hi
> 
> Thanks ;-) As for the 'DirFrontPAge' the error is below
> 
> Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown option
> 'DirFrontPage'.  Failing.

What is DirFrontPage supposed to be?  The manpage only mentions a
DirPortFrontPage.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Assigning new IP adrees to current relay

2016-11-29 Thread Sec INT 
Hi

Thanks ;-) As for the 'DirFrontPAge' the error is below

Nov 29 09:52:55.000 [warn] Failed to parse/validate config: Unknown option
'DirFrontPage'.  Failing.
Nov 29 09:52:55.000 [err] Reading config failed--see warnings above. For
usage, try -h.
Nov 29 09:52:55.000 [warn] Restart failed (config error?). Exiting.

the setting is

DirPort 80
DirFrontPage /etc/tor/tor-exit-notice.html
ExitPolicy accept *:20-21 # FTP - File Transfer Protocol (data /
control)
etc

the html page is working fine so its not that - it looks like DirFrontPAge
is an unknown option?

any thoughts?

cheers

Mark

On Mon, Nov 28, 2016 at 11:43 PM, Roger Dingledine  wrote:

> On Mon, Nov 28, 2016 at 11:25:29PM +, Sec INT wrote:
> > Hi Thanks for the reply - exit node is all up and running along with 6
> relays so all happy here - I decided just to keep the main IP
>
> Thanks for running relays!
>
> > One thing I did have was the DirFrontpage parameter in the torrc file
> >was badly formed so I commented it out but was wondering if anyone else
> >had that issue? It looks fine to me from what i can see in the sample file
>
> Can you clarify what you mean by badly formed?
>
> Basically that option takes a file and serves it out of the DirPort
> when people ask for the root ("/").
>
> So if the file that gets served is badly formed in your browser, then
> consider fixing the file. Whereas if it can't find the file, then
> consider pointing it at a file that really exists. :)
>
> Hope that helps,
> --Roger
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays