Automated firewall tests during whonix gateway startup

When whonix gateway starts, it checks if it can connect to the internet through tor and display an useful log message. This is handy. This helps noticing when things go wrong, like not so long ago when tor was failing to start due to the apparmor bug.

But this is not the only scenario to worry about.

How about this one: due to a bug in firewall, whonix gateway fails to block udp and this causes leaks. Strictly theoretically, does whonix gateway check for this scenario somewhere? Maybe it could at least display the firewall rules explicitly at startup (unless you think this is just lots of unwanted info on screen)?

In perspective, having this feature can serve whonix well, since linux is getting a new filtering stack and I expect firewalls to start breaking when people will start rewriting their netfilter/iptables rulesets.

since linux is getting a new filtering stack
Source?
How about this one: due to a bug in firewall, whonix gateway fails to block udp and this causes leaks.

I wouldn’t know how there could be a leak.

  • IP forwarding is disabled.
  • When Whonix-Gateway is offline, Whonix-Workstation cannot connect.
  • When Tor does not start or cannot connect, Whonix-Workstation cannot connect.
  • When Whonix-Gateway does not have load any firewall rules at all, Whonix-Workstation can only speak to Tor’s SocksPorts listening on Whonix-Gateway’s internal network eth1.
  • When Whonix-Gateway does not have load any firewall rules at all, even Whonix-Gateway itself can not connect to the internet. System DNS is disabled. Other applications (apt-get, sdwdate) are configured to use Tor SocksPort’s.
    (See also Install Additional Software Safely and read “All traffic from Whonix-Workstation and Whonix-Gateway is routed over Tor.” and the footnotes.)

On the contrary. I think enabling UDP clearnet access for Whonix-Workstation would be difficult. You first would have to enable IP forwarding, then follow some guide on how to use Linux as a router (such as How To Configure Ubuntu As The Router). All rules I’ve seen are all requiring IP forwarding, MASQUERADE and FORWARD. You can’t add such rules by accident (bug).

See also:

And also (not automated, unfortunately):

Maybe it could at least display the firewall rules explicitly at startup (unless you think this is just lots of unwanted info on screen)?

That would be the output of “sudo iptables --list”. Too much output to be useful. I can’t make head or tail of it without thinking hard about it. If it was shown at boot, I would probably ignore it.

What however could be to check on Whonix-Gateway could be the result of:

cat /proc/sys/net/ipv4/ip_forward

Which should always be.

0
Whonixcheck could automate that and do it on every boot and every time it's autorun. IP forwarding normally doesn't enable itself, but to prevent users from shooting their own feet, why not warn about it.
In perspective, having this feature can serve whonix well
Sure. By all means. Please contribute an automated test suite. Tails recently got one, perhaps some code can be re-used in Whonix or at least learn from it.

Source?[/quote]

Nftables is part of kernel 3.13. I didn’t document myself about how it works, but its syntax is sexy, much closer to the syntax of BSD firewalls, I believe this can be a great quick adoption reason.

I wouldn’t know how there could be a leak.

  • IP forwarding is disabled.
  • When Whonix-Gateway is offline, Whonix-Workstation cannot connect.
  • When Tor does not start or cannot connect, Whonix-Workstation cannot connect.
  • When Whonix-Gateway does not have load any firewall rules at all, Whonix-Workstation can only speak to Tor’s SocksPorts listening on Whonix-Gateway’s internal network eth1.
  • When Whonix-Gateway does not have load any firewall rules at all, even Whonix-Gateway itself can not connect to the internet. System DNS is disabled. Other applications (apt-get, sdwdate) are configured to use Tor SocksPort’s.
    (See also Install Additional Software Safely and read “All traffic from Whonix-Workstation and Whonix-Gateway is routed over Tor.” and the footnotes.)

On the contrary. I think enabling UDP clearnet access for Whonix-Workstation would be difficult. You first would have to enable IP forwarding, then follow some guide on how to use Linux as a router (such as How To Configure Ubuntu As The Router). All rules I’ve seen are all requiring IP forwarding, MASQUERADE and FORWARD. You can’t add such rules by accident (bug).[/quote]

Note that we talk about different things here. I mean the threat of leaks on gateway. You enumerate the features of the workstation. But in a general case, there’s no whonix workstation behind the gateway. There’s a very fresh forum post made by someone who is experimenting with windows as workstation. Now, while the official debian linux based workstation is and will be the main and most widely used workstation, it would be good to have some more transparency on the gateway about stuff that gets blocked on it by the firewall in the general case.

What made me think about this whole thing was Anonymize Other Operating Systems

Notice that it only mentions few basic network settings. Perhaps, as a first step, it could be improved to mention a minimum set of restricting, OS agnostic firewall rules that should be applied to the workstation. The idea is that we have to worry less about let’s say UDP leaks through the gateway if we configure the workstation behind it (not necessarily the whonix workstation, which is configured properly) to explicitly block outgoing UDP. So, the question becomes this: if the workstation has a default DROP policy for all network data, what’s a minimum set of ACCEPT rules to make it functional through the whonix gateway? I think having this mentioned somewhere in the wiki page mentioned above, in human language, not as reference to the whonix workstation firewall script, would make it a good addition. Just by analogy with the rest of network settings mentioned there: it tells what IP to set, what gateway address, what DNS server, could do the same for firewall rules.

You enumerate the features of the workstation.
These are Whonix features, not Whonix-Workstation specific features.
it would be good to have some more transparency on the gateway about stuff that gets blocked on it by the firewall in the general case.
Whonix-Gateway doesn't know if a Whonix-Default-Workstation or a Whonix-Custom-Workstation is being used. Best you could do is comment in the out commented log commands in Whonix-Gateway's firewall and watch the log. There is no /etc/whonix_firewall.d option for that yet but one could easily added if that was of any help. I doubt it will help, because what's logged in the firewall log, didn't leak. It was once useful when developing the firewall to see if everything works or if anything gets blocked which shouldn't be blocked. Also reading the log requires quite some knowledge about networking. Maybe there are any fancy graphical user interfaces making that a bit simpler to grasp.
Notice that it only mentions few basic network settings.
Which is the most important thing. Once you've set up the Whonix-Custom-Workstation to only have one network card which is only connected by an internal network ("Whonix") to Whonix-Gateway, there can't be any leaks. That's what I was talking about above as well.
Perhaps, as a first step, it could be improved to mention a minimum set of restricting, OS agnostic firewall rules that should be applied to the workstation.
A Whonix-Default/Custom-Workstation firewall is of limited use. Not zero, but limited. See Design Notes here: https://github.com/Whonix/Whonix/blob/master/man/whonix_workstation/whonix_firewall.8.ronn
The idea is that we have to worry less about let's say UDP leaks through the gateway if we configure the workstation behind it (not necessarily the whonix workstation, which is configured properly) to explicitly block outgoing UDP.
Whonix-Default-Workstation isn't configured by default to block UDP.

Whonix-Gateway blocks all UDP other than port 53 (DNS) traffic, which is forwarded to Tor’s DnsPort. (Unless you disable WORKSTATION_TRANSPARENT_DNS in /etc/whonix_firewall.d/.)

No help from Whonix-Default/Custom-Workstation required to prevent UDP leaks. Not requiring this, i.e. not requiring to trust Whonix-Default/Custom-Workstation is one of the most basic designs in Whonix.

So, the question becomes this: if the workstation has a default DROP policy for all network data,
It doesn't.
what's a minimum set of ACCEPT rules to make it functional through the whonix gateway?
Depends on how much functionality you want. You could block everything except connections to TCP-only IP 192.168.0.10 port 9100 and then use that Tor SocksPort with Tor Browser.
Just by analogy with the rest of network settings mentioned there: it tells what IP to set, what gateway address, what DNS server, could do the same for firewall rules.
The thing I could imagine adding there would be "Experts can have a look here: https://github.com/Whonix/Whonix/blob/master/whonix_workstation/usr/bin/whonix_firewall And consider applying this to the Whonix-Custom-Workstation.". I don't reserve a lot time to discuss Whonix-Workstation's firewall. It is one of the less important things to improve security.

That Anonymize Other Operating Systems article is too difficult anyway. Too few people are able to properly set up an operating system with all the features which a Whonix-Custom-Workstation has. Saying “Your responsibility to …” in the table (Anonymize Other Operating Systems) is more than non-ideal. I think things like secure network time synchronization are crucial. But how does one set that up on a Whonix-Custom-Ubuntu/Fedora/BSD-Workstation? I guess very few bother to extract the missing pieces from Whonix’s source code. I think time is better spend on other tickets (https://github.com/Whonix/Whonix/issues) such “as splitting Whonix into smaller packages” (https://github.com/Whonix/Whonix/issues/40). When that was implemented, installing the missing pieces such as sdwdate could be simpler if it was possible to run “sudo apt-get install sdwdate”.