Delivery-Date: Sun, 31 Jan 2016 21:21:21 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 7ADD21E0834;
	Sun, 31 Jan 2016 21:21:19 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id E1B6D3945C;
	Mon,  1 Feb 2016 02:21:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 1112C392B0
 for <tor-talk@lists.torproject.org>; Mon,  1 Feb 2016 02:21:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zEOJhWVTSYQy for <tor-talk@lists.torproject.org>;
 Mon,  1 Feb 2016 02:21:08 +0000 (UTC)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com
 [IPv6:2607:f8b0:400e:c00::231])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id B88073926F
 for <tor-talk@lists.torproject.org>; Mon,  1 Feb 2016 02:21:08 +0000 (UTC)
Received: by mail-pf0-x231.google.com with SMTP id 65so74609911pfd.2
 for <tor-talk@lists.torproject.org>; Sun, 31 Jan 2016 18:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=disposition-notification-to:return-receipt-to:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding
 :subject:from:date:to:message-id;
 bh=/aQguXqXTU68LL5qcb+uYwRHEYs3pfiuJeFlKjXKLoE=;
 b=d8jiJDPxqVkbzHSl76wT83qKcQhzQiLPscbUJGyiw2U9p7o+7EICHF7lOi4BERhc2f
 3qPkmXFwOPD12VpvfrPm8+cphBd5x2pp4kKR6GwYEsUiElBcuk4OfVyDLOz36fARtqpc
 Ied++xEHqq3oPvfFpQ9p8cQTb+9YWgu3zC6Gpaueq3HYZ/hQTfnSp6ubK0h52NXkneHC
 JN/EGH0wWyPpgrxhFhQeMT0Ao6Dd3Hase7TREOIKM4+RBR0sthtEhjfR6gFRsANDpgjC
 KoQzP+ATLXfal8coEjZlAaT4R8rgtikPBnt+UvJJz+5MqH1oaXWx+zr0c8TlI3lIJxO+
 eWWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:disposition-notification-to:return-receipt-to
 :in-reply-to:references:mime-version:content-type
 :content-transfer-encoding:subject:from:date:to:message-id;
 bh=/aQguXqXTU68LL5qcb+uYwRHEYs3pfiuJeFlKjXKLoE=;
 b=Dm+DnuMK9ArhIS4klbKrXjROndJppAV5K8pVOA1lIHfFvmKyvGEUCTKQJB/Td0yJXQ
 NL5cHnBOpQ3d+kLiv2r7hhDmSJ0NWks4HR8m5fJ4kNcDj8OyTbh59bkq5X4AK0aTO1bc
 jMZLmb9twD6drRnhoE2LXflEGebi69yglWwi3I/ElZvJ7XNzcojQWGxkm1PhKyaQnXPh
 X6z49s0iK0yX+lZ+HW0CZwVi4EYGMv3ZpBHy3EWddg9sQ5i2nwdNd0XD2EZK3L7E6ZqB
 8eK/N+WR3yZezC321iVGe9ojX0vKC2ai2/0nzHlheeaV6xW/g2rq9uwDP53/An1n0gYZ
 Qkgw==
X-Gm-Message-State: AG10YOS/k+/fEzE3DxNEsy25429zTggYy8OKHpnval5cX49JT0P/YEwAjAKKxb8/zgG14A==
X-Received: by 10.98.68.86 with SMTP id r83mr13879429pfa.12.1454293266089;
 Sun, 31 Jan 2016 18:21:06 -0800 (PST)
Received: from [192.168.3.128] (c-76-22-98-172.hsd1.wa.comcast.net.
 [76.22.98.172])
 by smtp.gmail.com with ESMTPSA id n84sm38671968pfa.45.2016.01.31.18.21.04
 for <tor-talk@lists.torproject.org>
 (version=TLSv1/SSLv3 cipher=OTHER);
 Sun, 31 Jan 2016 18:21:04 -0800 (PST)
In-Reply-To: <CAJVRA1T778ANkQwTZ6qFwAhxCxUfXpp=ZAYuU9K1WY+_HzKWeQ@mail.gmail.com>
References: <0C175F9B-9446-41E7-9479-A52E3589F379@gmail.com>
 <CAJVRA1SX3wFFm519DXQsYcRYSkRbzJDXJGe+ctj=V1Yeon47yg@mail.gmail.com>
 <C70326E8-0427-4D41-9B0D-4F7D0767D4E1@gmail.com>
 <CAFN1edpi8F=7rGz5HVk5KMFPPLGrgnYCsAarVQMno0AdeRaZ6Q@mail.gmail.com>
 <C83CD66C-0737-421D-8F24-C128A698BEC9@gmail.com>
 <CAFN1edrZn0pMAAsYYkBJrThdxMgVpOsw3xtwXyYTTH+okKkVOg@mail.gmail.com>
 <9C7C7D1C-06A3-4589-923F-C8C50BC222A4@gmail.com>
 <CAFN1edrawns_+LTOAnjs4_VAikKm4A1t9CU+3FrEW_YkAXnjeA@mail.gmail.com>
 <CAJVRA1T778ANkQwTZ6qFwAhxCxUfXpp=ZAYuU9K1WY+_HzKWeQ@mail.gmail.com>
MIME-Version: 1.0
From: Michael <strangerthanbland@gmail.com>
Date: Sun, 31 Jan 2016 18:21:37 -0800
To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
Message-ID: <C7FBA10B-7C46-4464-AF60-EAA715B5A70C@gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Scripted installer of Tor and more being worked on
	at GitHub, ya may want to sit down for this...
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

David,

I'll happily aid in testing and coding a Python translated version
if we can find an easy way of adding it to a custom build of BusyBox
or installing from source onto Android without chroot. My biggest
concern is portability and compatibility with as many devices as
possible because I plan to make a "BadUSB" and "ADB" wrapper. 
I've begun documenting the configurations that the current
version outputs into a project Wiki to help anyone that wants to
help get a jump on translating to any other languages while I continue
to add the remaining features ~

https://github.com/S0AndS0/Perinoid_Linux_Project/wiki/Config_Examples_Torrc_Bridge

~ and here's a link that may turn some of those frowns ya 
mentioned upside down, as it documents the custom set of
Bash functions that where written to make things a bit easier
to maintain. ~

https://github.com/S0AndS0/Perinoid_Linux_Project/wiki/Sandcastle_Arg_checker

~ Even if the current project moves to another language the above
should give frowners a reason to grin when they understand how
this can be used for "niche circumstances" on other projects ;-)
for the most part this script pack is a just a very simple set of `if`,
`for` and `case` statements so translation should be a trivial task.

The "haters" are more than welcome to, so long as the emotion
can be channelled towards building something constructive with
this project I've no reason to dissuade them from their feelings.
Truth be told if I didn't already know that Java would have received
more push back than Bash I would have tried to express this in 
Nodejs/NoFlo~

https://github.com/noflo/noflo

~ because it offers a more visual way of showing scripted logic.
But I've seen how people cringe at I2P's use of Java so I went to
what I knew to be pretty universally understood so that we can have
the logics and configurations mapped out without confusion and 
suspicions getting in the way.

Thanks David, I may need much in the way of luck in the future.
The "cross pollination" of education is exactly what I was hoping
for and from checking out what others have started or "stared"
I've already seen a few things I want to add as options for 
installation from this project such as ~

- for some hardcore filtering rules
https://github.com/jakeogh/dnsgate

- and this looks to be an amazing delivery system that 
"whistle blowers" could use for initial publishing of information.
https://github.com/tryforsure/ephemeral2

- And one of the best BTC+GitHub combos I've seen, which I may use
for this project in the future so code maintainers get something for their
contributions automatically.
https://github.com/WhisperSystems/BitHub

~ in short I'm learning a great deal from you all and am very
thankful for it.

####

For all readers I've a few Q's that could use some A's,
I've been working on the firewall scripted portion of this project ~

https://github.com/S0AndS0/Perinoid_Linux_Project/blob/master/functions/shared/output_iptables_varfile.sh

~ so far as I know Tor nodes use only TCP protocol (even for DNS?)
so I'll be adding each node's various ports via ~

` _tcp_ports="${ _tcp_ports},${_some_tor_port1},${_some_tor_port2}"`

~ and then have the `for` loop in ~

https://github.com/S0AndS0/Perinoid_Linux_Project/blob/master/firewall/functions/input_chains/input_tcp_filters.sh

~ and it's in/output counterparts for IPv6 to parse which
ports will be opened and or forwarded through the firewall.

My biggest questions are with forwarding chains and where to
place jumps to these filtering chains from the default iptables forward
chain for best performance. 
For example should `in_tcp` be used on `preroute` or `forward` chain?
And should the `out_tcp` be used on `postroute` or somewhere else?

Having an answer to these questions will allow me to push forward
with having a "proof of concept" version completed for not just
Tor and related software but also allow for "jailing" various packages
from one another on their own bridged network interfaces to keep
security breaches a bit more contained.

My last question (for now) has to do with Fail2Ban and hidden services.

My question is would you all prefer that separate jail.local configuration
blocks be written for each Tor service port individually, ei failing one port
doesn't ban from a possible second hidden service port, or is a fail one
ban'em all sufficient?

I see that the first option would make it harder for an attacker to be 100%
sure that two hidden services lead to two ports on one physical machine.
But would allow for repeated attacks on all available ports before all filters
ban their interactions.
And I see that the second option would limit attack surface but would also
allow for leakage of info as to what hidden services might be running on 
the same device. 
A tough call so I'm all ears on how we should proceed.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

