I need to make one of whonix gateways to allow only traffic to specific ips only. Better with DNS (any host resolved but not connected) or without it is also fine.
I tried applying regular iptables rules, like in forward chain but it looks like they got messed up with whonix ones and also it doesnot persist.
So how can I do that properly?
Thanks
Whonix firewall supports dropping in custom snippets/rules that run in addition to the defaults.
See this link for making an IP and port whitelist.
Also depending on your threat model, state adversaries don’t need to send traffic to their own servers to be able to collect exfiltrated data. Any allowed clearnet destination is enough.
I know how to do it basically, just drop the forward chain. But the problem last time I tried to drop something from forward chain the rules didnt applied, then I tried iptables -I FORWARD and it worked but then it got overwritten by something
then I list all rules and dont understand a single thing what is routing there and how. So I wonder which specific chain should I tamper and how to do it persistently? Maybe some config or something
And I just need my sandboxed software to access specific set of ips, and nothing else nor any other software access anything except the set of ips, thats the use case. And also I need it on gateway not on workstation. Workstation is windows in this case which I tryna isolate.
I am not sure that is possible. As per Free Support for Whonix ™ here is an exercise for you:
Set up a machine or VM with Debian, install Tor, install Tor Browser… Make Tor Browser use the locally installed Tor. Or better. Tor Browser in one VM and Tor in another VM connected through an internal-only LAN network (gateway / workstation model).
Then somehow by using iptables or otherwise allow Tor to only connect to whitelisted destinations.
Once you can confirm success for this experiment and describe how you did it we can look into Whonix integration.
But I am fairly concerned whonix does transparent proxying for something like redsocks. So since it acts as a gateway why cant it filter the packets by dst?
I could do that easily if I put some debian vm between whonix and workstation it will just eat more RAM. So why cant I do it properly in whonix iptables?
On intermediate debian gateway I mean something like
iptables -P FORWARD DROP
iptables -A FORWARD -p tcp -d 1.1.1.1 -j ACCEPT
And I am speaking about just transparent proxying right now and whonix-gateway. Nothing related to whonix-workstation with socks ports configured inside the apps. So setting up tor browser locally and tor remotely and connecting to its socks port is completely irrelevant (that case could be solved with intermediate danted socks server tho, it can filter by subnets/ips and supports upstream socks)
As for socks:
No, Tor Browser inside Whonix effective talks to a Tor SocksPort. No transparent proxying for Tor Browser. References:
As for transparent proxying:
Whonix does not use IP forwarding, does not use net.ipv4.ip_forward. Not required. Discouraged. Disabled on purpose.
It also blocks all forwarding with iptables.
ipv4_forward() {
## Log.
#$iptables_cmd -A FORWARD -j LOG --log-prefix "Whonix blocked forward4: "
## Reject everything.
$iptables_cmd -A FORWARD -j REJECT --reject-with icmp-admin-prohibited
}
In that case the exercise for you would be setting up a Tor Transparent Proxy, Anonymizing Middlebox as per TransparentProxy · Wiki · Legacy / Trac · GitLab without IP forwarding and then implement IP whitelisting. Once you have that, we can look into Whonix integration.
You could also edit /usr/bin/whonix-gateway-firewall directly for testing. But above perhaps shorter, more easy. More permanent changes could be considered once the exercise was a success. Currently the firewall script doesn’t allow easily injection of iptables rules at any place and I wouldn’t know how to offer such configuration flexibility since I haven’t ever seen that elsewhere. Open for suggestions.
hmm I wonder what happens if I replace tor trasparent port with dante-server transparent port and setup dante to use tor as upstream. Then I can write the pass/block rules there. Might be easier solution for my case since forward chains are not used somehow.
Oh also since you are open to some enhancements I’d also would like to propose make an option in whonix-setup that will allow autologin on 1st terminal and opens arm there after each boot. Always doing that manually for each new whonix. When gateway-CLI is used locally there is no need for that password prompt, its much more convinient to have arm opened straight away after boot to press “n” for new identity when tor cant connect somewhere. Its literally the only thing I am using whonix-gateway-cli console for after I did initial setup (if any). If one needs shell prompt he can still get to second tty which would still have prompt.
Ok I was able to do it and with some clear approach. Instead of messing with iptables and chains I dont understand I installed redsocks and dante-server with apt-get.
Then I disabled TrasnPort 10.152.152.10:9040 in /usr/share/tor/tor-service-defaults-torrc.anondist
After this I configured redsocks to bind transparent port on 10.152.152.10:9040, commented out dns and udp related stuff and pointed it to dante-server on 127.0.0.1:1080
base {
log_debug = off;
log_info = on;
log = "syslog:daemon";
daemon = on;
user = redsocks;
group = redsocks;
redirector = iptables;
}
redsocks {
local_ip = 10.152.152.10;
local_port = 9040;
ip = 127.0.0.1;
port = 1080;
type = socks5;
}
Then I configured dante server as follows to allow only access to specific hosts and use tor socks bound to 10.152.152.10:9050 as upstream
logoutput: stderr
internal: lo port = 1080
external: lo
socksmethod: none
clientmethod: none
user.privileged: proxy
user.unprivileged: nobody
user.libwrap: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect disconnect error
}
socks pass {
from: 0.0.0.0/0 to: 1.1.1.1/32
log: connect disconnect error
}
socks pass {
from: 0.0.0.0/0 to: 1.1.1.2/32
log: connect disconnect error
}
route {
from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.152.152.10 port = 9050
}
So this allowed ips 1.1.1.1 and 1.1.1.2. DNS is also allowed, it still goes thru tor directly but the following tcp connection wont work. Onion addresses will resolve but wont connect since they are on 10.* subnet or something
If I unbind all other socks ports bound to 10.152.152.10, and rebind 10.152.152.10:9050 to something local I get a sandbox that can only talk to specified ips,resolve any dns and cant escape this jail
If I want to setup dns filtering as well, then need to mitm that tor dns port :5300 with dnsproxy pkg (or dnsmasq). Those can allow or forbid specific dns and support upstream dns.
So I achieved what I wanted with this thing, also can log connections in dante-server for futher forensics. If you think I reinvented the wheel well editing dante config is much more convenient than messing with iptables. Theres some overhead nd, but not important in my case.
Glad Whonix could be reconfigured to accomplish that. Certainly a non-trivial modification this one.
A safer why might be to disable transparent proxying on Whonix-Gateway:
Stream Isolation
And then do the filtering inside Whonix-Workstation. That way no additional software would run on Whonix-Gateway.
Dunno what that does.
I suggest to record iptables rules prior modification (perhaps a separate unmodified Whonix-Gateway) and then compare to modified one. Similar to this process:
In short, run in both VMs:
sudo iptables-save-deterministic
And compare output with a diff viewer.
This will unfortunately be overwritten on upgrades. It might be possible to edit Edit Tor Configuration and to use TransPort 0 or so to disable. Untested.
That is very far from the IP Whitelist topic. Therefore please separate forum thread.
Also while technical suggestions how Whonix firewall customization could be made easier are welcome, that would also be better in a separate forum thread.
No its just instruction how to parse the packets, it does not invoke iptables.
Good point but I feel that upgrades better to be done by downloading fresh ova (unless running on physical isolation host or other custom kind of use cases)
I dont feel that mine use case is any sense for implementing in whonix release. Because adding redsocks and danted to the setup that just redirects the traffic to tor is redundant. It adds additional overhead, nd adds 2 additional narrow points (both redsocks and danted might have vulnerabilities)
Its something for whonix wiki I suppose but not for the release.
offshorebats via Whonix Forum:
Good point but I feel that upgrades better to be done by downloading fresh ova (unless running on physical isolation host or other custom kind of use cases)
Sometimes there are Tor upgrades or in case of a Tor package security
issue there might be an upgrade quite some time before a new image is
released.