[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

whonix, torrents, and being a good tor citizen

Working notes … continuing …

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.
    [/quote]

For 2: Internally. whonix already has several proxies in play, be it browser, e-mail, or generally. By definition, and desire, all go through tor. It is the point of using whonix. Yet not all programs have settings to set proxies, http, socks4|5, or otherwise, so there is no easy or universal way by which to except particular traffic beside tor rather than through it.

Except, that is, for using a vpn, which is by definition a proxy, and routing all traffic through it. Yes, this is trusting that the vpn provider (truly) is anonymous, or sufficiently so. However, anonymity is -the- selling feature of many VPNs. OTOH … no way to prove a negative. It’s anonymous, until it isn’t, and by then it’s too late. Hopefully word will get out on providers that aren’t, and hopefully all concerned are paying attention when it does.

But then, I suppose the possibility is no worse than the possibility of a compromised tor node or honey trap.


So, for 2 - VPN. From a trusted provider.

Aside from using a VPN, the particulars of effecting non-tor traffic on whonix will be discussed another time. It will likely involve iptables rules, routing, and perhaps even policy based routing.

For 1, the challenge of identifying particular traffic so it may be constrained as desired, outside of tor, yet within the vpn (else one wouldn’t be using whonix at all) …

Solution, part a: Create and use an additional interface, and associated IP address, and thus provide breadcrumbs by which the whonix gateway can identify, permit, and route, particular traffic, and only that particular traffic, directly to the VPN.

One way to do this would be to create an additional virtualbox, internal network only, interface on both the whonix workstation, and gateway.

However, I instead propose creating a virtual interface on workstation only. Thus only users interested in this particular facility, and having manually installed it, are affected, and only when so running such designated programs. Impact is specific, leaving all other whonix safeguards in place, and in play.

On workstation:

First - # apt-get install bridge-utils

Manually -

brctl addbr br0
brctl addif br0 eth0
ip tuntap add dev tap0 mode tap
ifconfig tap0 192.168.2.1 up
brctl addif br0 tap0

Automatically:

  • mv /etc/network/interfaces.d/30_non-qubes-whonix /etc/network
  • this mv probably shouldn’t be needed / isn’t appropriate, but I haven’t gotten it to work by merely adding the tap0 and br0 bits to a separate file such as /etc/network/interfaces.d/50_user_add_whonix.
  • append to /etc/network/interfaces:

    auto lo
    iface lo inet loopback

iface eth0 inet manual

auto tap0
iface tap0 inet manual
pre-up ip tuntap add dev tap0 mode tap
pre-up ip addr add 192.168.2.1/24 dev tap0
up ip link set dev tap0 up

auto br0
iface br0 inet static
bridge_ports eth0 tap0
address 10.152.152.11
netmask 255.255.192.0
gateway 10.152.152.10

#ip tuntap add dev tap0 mode tap
#ifconfig tap0 192.168.1.1 up
#brctl addif br0 tap0

  • alternately, put the above in something like /etc/network/interfaces.d/50_user_add_whonix, but I haven’t tested that.

Leaving a distinct ip address (192.168.2.1) / interface (tap0) upon which to set a designated program to use, and by which the whonix gateway can discern such traffic.

e.g. Some torrent clients have a setting to designate the interface, or ip address, to use.

On gateway:

Pre-test:

ping 192.168.2.1 # - no response, expected.

Modify or create a file in /etc/whonix_firewall.d, such as 50_user_conf, creating or modifying a section to look like:

## Destinations you don not want routed through the VPN.
## 10.0.2.2/24: VirtualBox DHCP
#LOCAL_NET=“127.0.0.0/8 10.152.152.0/24 10.0.2.2/24”
#LOCAL_NET="
# 127.0.0.0-127.0.0.24
# 192.168.0.0-192.168.0.24
# 192.168.1.0-192.168.1.24
# 10.152.152.0-10.152.152.24
# 10.0.2.2-10.0.2.24
#"
LOCAL_NET="
127.0.0.0-127.0.0.24
192.168.2.0-192.168.2.24
10.152.152.0-10.152.152.24
10.0.2.2-10.0.2.24
"

Manually -

route add -net 192.168.2.0/24 dev eth1

Automatically - edit /etc/network/interfaces.d/30_non-qubes-whonix:

  • append a line to the ‘iface eth inet static’ section:

    <tab> up route add -net 192.168.2.0/24 gw 10.152.152.11

Alternately: Add ‘route add -net 192.168.2.0/24 gw 10.152.152.11’ to 50_user_conf above, rather than messing with files under /etc/network.

Run “whonix_firewall” to manually effect the change, without rebooting.

Test:
ping 10.152.152.11 # - should work, as expected.
ping 192.168.2.1 # - should work, now.


Next up, Solution, part b combining the individually incompletely effective fixsrcip and force_bind together, to be more completely effective.


And beyond that, Solution, part c will be necessary gateway iptables changes to make the whole work.

Suggestions/enhancements most certainly welcome. Especially for anything suggested that’s actually inadvertently rather ‘dumb’ -particularly, from a whonix community / purpose perspective. Especially anything that pertains to where best to place / plug in this stuff for other whonix users so interested, to find.

Working notes … continuing …

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.
    .
    .
    .
    So, for 2 - VPN. From a trusted provider.

Aside from using a VPN, the particulars of effecting non-tor traffic on whonix will be discussed another time. It will likely involve iptables rules, routing, and perhaps even policy based routing.

For 1, the challenge of identifying particular traffic so it may be constrained as desired, outside of tor, yet within the vpn (else one wouldn’t be using whonix at all) …

Solution, part a: Create and use an additional interface, and associated IP address, and thus provide breadcrumbs by which the whonix gateway can identify, permit, and route, particular traffic, and only that particular traffic, directly to the VPN.

One way to do this would be to create an additional virtualbox, internal network only, interface on both the whonix workstation, and gateway.

However, I instead propose creating a virtual interface on workstation only. …

{Creation of br0 …}[/quote]

Continuing here with Solution, part b: Constraining a program / application’s IP traffic to a designated address …

I have combined / expanded / ‘enhanced’ the individually incompletely effective fixsrcip and force_bind together, creating runfromiptcpudp

Usage: runfromiptcpudp {ip address} {program}
e.g., per prior post: runfromiptcpudp 192.168.2.1 qbittorrent

Having pinned the program to an ip, traffic is corralled, and part c, what to do with the now identified traffic, can proceed.

Enhancements include:
- exiting if the specified IP doesn’t exist on an interface (rather than proceeding anyways!).
- more verbosity / better syslog’ging whereby a user can figure out what all a program is doing / IPs being used.

Degradation includes:
- fixsrcip is not IPv6 aware, while force_bind is. However, although the runfromiptcpudp combination doesn’t remove that awareness, it has not yet been extended to the fixsrcip base. Thus, until such experts apply their expertise to the code, IPv6 traffic is denied. (Which some may agree is no bad thing.)

Consequences include:
- traffic that escapes a program is either denied, or gets handled and appropriately scrubbed by the current whonix facility. e.g. Despite being so pinned, ktorrent leaks traffic (being a KDE program) - which still gets tor’ified.
- local network broadcasts get muted. (Since they become bound to an IP, not 0.0.0.0).
- A program is independently network encapsulated, without the overhead of LXC, and traffic sysloggable. Providing, consequently, an independent trapping / logging mechanism for 3rd party programs.

To make use of / install:

$ mkdir ~/local/src; cd ~/local/src
$ git clone https://github.com/rAntOCauDgb/runfromiptcpudp.git
$ ./INSTALL #(which merely calls make; make install.)

Having set up br0 as per prior message in this thread:

runfromiptcpudp 192.168.2.1 {program}

And traffic is corralled, as desired.


Next up, Solution, part c will be necessary gateway iptables changes to make the whole work.

Working notes … final.

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.

    So, for 2 - VPN. From a trusted provider.

For 1, part a, identifying particular traffic and constraining as desired, runfromiptcpudp as discussed.
[/quote]

Concluding here with 1, Solution part b: Permitting and appropriately routing the designated traffic.

Note: Presented is a way of whonix, torrents, and being a good tor citizen. Proof of concept. Only. Although the steps and details are correct, the specifics of implementing them are suitable only for individual experimentation and use. For general use or implementation, a more robust installation would be required. See Bolt on for whonix_firewall - best place to put files? for such beginnings, and particularly Dev/Firewall Refactoring.

Environment: For the purposes of development / proof of concept, whonix_firewall was ‘cloned’ (and gutted) to whonix_firewall-post, and associated /etc/whonix_firewall-post.d directory clone of /etc/whonix_firewall.d created.(Thank you Patrick!) Specifics can be seen at whonix-torexceptedtraffic_proofofconcept Only the summary / details are shown below.

Assumption: Appropriate settings placed in a file in /etc/whonix_firewall.d, as per /etc/whonix_firewall/30_default, settings such as ‘50_user.conf’:
VPN_FIREWALL=1
VPN_SERVERS="10.0.1.2"
VPN_INTERFACE=tun0
LOCAL_NET="
127.0.0.0-127.0.0.24
192.168.2.1-192.168.2.1
10.152.152.0-10.152.152.24
10.0.2.2-10.0.2.24
"

On Whonix Gateway:

Preparation:
(1) /usr/local/bin/whonix_firewall-post - essentially just the top part of whonix_firewall, the sourcing and executing of files within a designated .d directory.
(2) /etc/whonix_firewall-post.d/30_lastrules_to_envvars - essentially just the environment variables of whonix_firewall, -and- the storing of the last / dropping rules of each chain, so that iptables changes can be modularly implemented.

  • Each .d file utilizes a lock file so it can’t run twice / double iptables rules.

e.g.:
# Delete old iptables INPUT last rule.
$iptables_cmd -D $IPT_FILTER_INPUT_LASTRULE

< insert appropriate iptables script lines for this module >

Reapply old iptables INPUT last rule.

$iptables_cmd -A $IPT_FILTER_INPUT_LASTRULE

Note: This is NOT how whonix would implement this facility. This mechanism is only useful during the process of development / debugging / discerning correct steps. See Bolt on for whonix_firewall - best place to put files? and/or Dev/Firewall Refactoring for a better implementation mechanism.

/etc/whonix_firewall-post.d/70_torexcept:
iam=$(basename $BASH_SOURCE)
mylockfile=/run/lock/WFP_${iam}_run

if [ -e “$mylockfile” ]; then
echo ; echo $iam already run, lockfile $mylockfile present. Returning without running.
return 0
fi

echo ; echo Running $iam, setting lockfile ${mylockfile}.
touch $mylockfile

whonix_firewall permits multiple VPN servers to be specified, space separated.

iptables, OTOH, requires the servers to be comma separated.

VPNIPS="${VPN_SERVERS// /,}"
echo -e “\nExtrapolating VPN IPs of ‘$VPNIPS’ from ‘$VPN_SERVERS’.\n”

For the moment, put in log entries … skipped for the purposes of this forum thread.

Note that iptables -t nat INPUT, OUTPUT, and POSTROUTING, default to accept.

- note that -t nat OUTPUT RETURNS if uid cleanet.

Note: whonix_firewall INPUT rules:

- drop all weird/erroneous things

- accept all in from lo

- accept all established

- deny all icmp

- allow all in from tun0

- drop all (last rule)

set -v -x

----------------------------------------

Delete current iptables INPUT last rule.

$iptables_cmd -D $IPT_FILTER_INPUT_LASTRULE

{Placeholder Line: Turns out no rules needed. Logging rules in ‘source’ file handy.}

Reapply old iptables INPUT last rule.

$iptables_cmd -A $IPT_FILTER_INPUT_LASTRULE

---------------------------------------

Note: whonix_firewall FORWARD REJECT all (last rule)

---------------------------------------

Delete current iptables FORWARD last rule.

$iptables_cmd -D $IPT_FILTER_FORWARD_LASTRULE

$iptables_cmd -A FORWARD -i $INT_IF -o $VPN_INTERFACE -s $XCEPTIP -j ACCEPT
$iptables_cmd -A FORWARD -i $VPN_INTERFACE -o $INT_IF -d $XCEPTIP -j ACCEPT

Torrents want to talk to VPN server (presumably) to open ports for

forwarding. (*1)

$iptables_cmd -A FORWARD -i $INT_IF -s $XCEPTIP -d $VPNIPS -j ACCEPT

Reapply old iptables FORWARD last rule.

$iptables_cmd -A $IPT_FILTER_FORWARD_LASTRULE

---------------------------------------

Note: whonix_firewall OUTPUT rules:

- reject all weird/erroneous things

- accept all to tun0

- accept all established

- accept all LOCAL_NETS

- accept all to vpn server ip

- accept all from clearnet userid

- reject all (last rule)

---------------------------------------

Delete current iptables OUTPUT last rule.

iptables -D $IPT_FILTER_OUTPUT_LASTRULE

{Placeholder Line: Turns out no rules needed. Logging rules in ‘source’ file handy.}

Reapply old iptables FORWARD last rule.

$iptables_cmd -A $IPT_FILTER_OUTPUT_LASTRULE

---------------------------------------

Note: whonix_firewall -t nat PREROUTING rules:

- redir (incoming) eth1 tor/9xxx ports to self (tor) equivalents.

- redir eth1 udp/dns to self (tor) :5300

- redir eth1 tcp to self: 9040 (tor) (last rule)

---------------------------------------

Delete old iptables -t nat PREROUTING last rule.

$iptables_cmd -t nat -D $IPT_NAT_PREROUTING_LASTRULE

$iptables_cmd -t nat -I PREROUTING -i $INT_IF -s $XCEPTIP -j ACCEPT

Reapply old iptables -t nat PREROUTING last rule.

$iptables_cmd -t nat -A $IPT_NAT_PREROUTING_LASTRULE

---------------------------------------

Note: whonix_firewall -t nat INPUT rules: none.

- Default ACCEPT, so won’t be in any way.

Note: whonix_firewall -t nat OUTPUT rules: none.

- Default ACCEPT, so won’t be in any way.

Note: whonix_firewall -t nat POSTROUTING rules: none.

- Default ACCEPT, so won’t be in any way.

---------------------------------------

Delete old iptables -t nat POSTOUTING last rule.

- except … it doesn’t currently have any rules.

$iptables_cmd -t nat -D $IPT_NAT_POSTROUTING_LASTRULE

iptables -t nat -A POSTROUTING -o $VPN_INTERFACE -s $XCEPTIP -j MASQUERADE

See (*1).

$iptables_cmd -t nat -A POSTROUTING -s $XCEPTIP -d $VPNIPS -j MASQUERADE

Reapply old iptables -t nat POSTROUTING last rule.

$iptables_cmd -t nat -A $IPT_NAT_POSTROUTING_LASTRULE

---------------------------------------

set +v +x
echo

Enable forwarding.

echo -n "/proc/sys/net/ipv4/ip_forward \(forwarding\) was: "
cat /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
echo -n "/proc/sys/net/ipv4/ip_forward \(forwarding\) now: "
cat /proc/sys/net/ipv4/ip_forward

return 0

To effect: $ sudo whonix_firewall-post


Complete and more extensive details can be seen at whonix-torexceptedtraffic_proofofconcept

fini


Comments, suggestions, welcome.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]