Traffic monitoring and better control

[zrtqee]

I would like to have a better picture of network traffic in Whonix.

First, I want to look into OS-initiated traffic (when the user doesn’t open any applications or performs any actions at all). Where does Whonix initiate connections to? Anything apart from the sdwdate lists? I want to look all the related code for those operations.

In general though, the monitoring I have in mind should include all traffic.

Ideally I would like to have a service that shows, at any given time, a list of connections, with:

• The process initiating the connection
• Destination of the connection

this should include both clearnet and onion destinations, and with a readable, concise log.

At a second stage, perhaps a blacklisting / whitelisting mechanism.

Examples for whitelisting use cases:

• A workstation is used for Electrum only. The user wants to only allow connections to certain bitcoin nodes, plus anything that is absolutely a must for Whonix to function (debian / whonix updates, sdwdate?). Nothing else.
• A workstation is used for chat with Gajim for example. After an initial research into the required destinations, only those are whitelisted.
• A workstation is used only for email using say protonmail.com. Whitelisting of their site only (I don’t think they load scripts from elsewhere. If so, review and whitelist those as necessary).
• A workstation is used to manage a remote server. Only that IP is whitelisted.
• When working with a longer list of sites: assists in avoiding phishing attacks.

Motivation: prevent both mistakes and malicious outgoing connections / destinations. A malware will need to circumvent the whitelisting mechanism itself to work (perhaps the whitelisting should be done on the Gateway?).

Perhaps some of that is already possible. I will appreciate any comments, pointers and advice.

[zrtqee]

Will help solve or at least reduce the risk of issues discussed in:

walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode

Using Empire, I generated a bash launcher and saved it on the target (Whonix workstation 13). Added +x and ran it. This launcher runs a base64 encoded python script. The steps above require some convincing aka social engineering (or just being naive about security of this or that system). The rest doesn’t. Seconds after the script silently runs (and deletes itself) I have a shell into Whonix Workstation. I use a ruby keylogger module, and hey, I’m lucky today, the user runs sudo apt-get updat…

Simple clearnet connection proof of concept for Tails

Unlike in Whonix, it’s very easy to start a clearnet connection in Tails - one can use the "Unsafe browser’ (included for the purpose of connecting to captive networks). https://tails.boum.org/contribute/design/Unsafe_Browser/ This browser comes with many warnings though to prevent the user from gaining a false sense of safely. The browser runs with the clearnet user. Code for that is at the above link. I am looking for a simple proof of concept though, demonstrating that a simple bash scrip…

TransPort = privacy issue

Why does whonix Gateway allows TransPort by default? For convenience? It is security and privacy issue. If you use botnet OS like Windows for Whonix-Workstation, it can communicate with NSA or Microsoft easily, since all traffic will just be sent through Tor by TransPort. However, TransPort allows to use socks proxies in TBB, so not sure if to disable it.

[HulaHoop]

@zrtqee

Motivation: prevent both mistakes and malicious outgoing connections / destinations. A malware will need to circumvent the whitelisting mechanism itself to work (perhaps the whitelisting should be done on the Gateway?).

Monitoring can be done with many tools such as wireshark.

Your goal of preveting leaks by limiting destinations is however a pipe dream. If ANY connection is allowed to the outside, an adversary (especially one monitoring the entire internet) could easily exfiltrate that information even if sent to whitelisted IPs. Also with encryption, there is no way an IDS can catch everything. Also don’t forget about steganography where non-apparent changes in the TCP packet layer can be used to encode data and send it in plain sight.

Even if no connections are allowed there is the risk of a clever malware using side-channels to affect legit traffic outside the VM on the same machine to leak data.

[sheep]

I believe you can use iptables for such whitelisting.

[zrtqee1]

Replying from a new account since I didn’t keep the credentials to the old one.

@HulaHoop

Monitoring can be done with many tools such as wireshark.

Thanks @HulaHoop for your response. I’ve used tcpdump so far in a Workstation, all packets are (as expected) between the Workstation and the Gateway, not easy to find the destination IP. Running it with -A shows http requests with the destination IP however parsing it will probably be less easy with other applications. I suspect I will have a similar issue with wireshark.

@HulaHoop

Your goal of preveting leaks by limiting destinations is however a pipe dream. If ANY connection is allowed to the outside, an adversary (especially one monitoring the entire internet) could easily exfiltrate that information even if sent to whitelisted IPs. Also with encryption, there is no way an IDS can catch everything. Also don’t forget about steganography where non-apparent changes in the TCP packet layer can be used to encode data and send it in plain sight.

Even if no connections are allowed there is the risk of a clever malware using side-channels to affect legit traffic outside the VM on the same machine to leak data.

No intention to solve all of those issues, certainly not battle an adversary that monitors the entire internet.

Without advanced means, a malware would need to be very clever indeed to adapt itself to specific destinations that it can manipulate, if such exist in the list (for example to send info through it’s own protonmail account).

Recent example - the exploit on electrum, where user were prompted through it’s messaging system to download a new version, then the malware is downloaded. This exploit could not have worked with the same ease in a whitelisted environment.

Qubes already provides an easily editable firewall.

Firewall

Can we consider building a similar (basic, simpler) functionality in VirtualBox Whonix-Gateway?

@sheep

I believe you can use iptables for such whitelisting.

OK. I am weary however to mess with the Gateway’s iptables. Easier with http://ipset.netfilter.org/ ?

[Patrick]

@zrtqee1

Can we consider building a similar (basic, simpler) functionality in VirtualBox Whonix-Gateway?

This and walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode is interesting.

• Frequently Asked Questions - Whonix FAQ
• Frequently Asked Questions - Whonix FAQ

[HulaHoop]

@zrtqee1

I’ve used tcpdump so far in a Workstation, all packets are (as expected) between the Workstation and the Gateway, not easy to find the destination IP.

For that you need to run it on the host and listen on your physical NIC

@zrtqee1

Can we consider building a similar (basic, simpler) functionality in VirtualBox Whonix-Gateway?

There are firewall for Debian now that can restrict outgoing connections per program but I can;t remember its name nor if it has made it into upstream repos.

[Patrick]

This is actually a missing feature in Tor. For why, see [1].

Tor feature request draft:

subject:

allow Tor clients to restrict which IPs / ports they can connect to

text:

syntax

currently:
SocksPort [address:]port|unix:path|auto [flags] [isolation flags]

suggested:
SocksPort [address:]port|unix:path|auto [flags] [isolation flags] [whitelist_ip_port:IP[/MASK][:PORT]] [whitelist_ip:IP] [whitelist_onion:onion] [whitelist_port:port] [OnionTrafficOnly]

Similar for TransPort / DnsPort.

The best syntax is not clear to me. If you have better ideas, by all means.

Examples for whitelisting use cases:

• A Tor SocksPort is used for Electrum (or any bitcoin client) only. The user wants to only allow connections to certain Electrum nodes.
• A Tor SocksPort is used for chat with Gajim for example. After an initial research into the required destinations, only those are whitelisted.
• A Tor SocksPort is used only for email using say for some-service.org only. Whitelisting of their site only.
• A Tor SocksPort is used to manage a remote server. Only that IP is whitelisted.

Motivation

Prevent both user mistakes and malicious outgoing connections / destinations. Malware would need to circumvent the whitelisting mechanism itself which would require special support by the malware for this. When restricting by outgoing IP or onion service, this may not be simple for malware writers (who might defer to easier targets). Might prevent some exploitation. If a vulnerable application gets a malicious, exploitable reply with a request to download code from a non-whitelisted IP, onion service or port, this would be blocked.

Of course this is only a building block. Restrictive firewall rules etc. are required as a prerequisite which is out of scope here.

OnionTrafficOnly is a similar already existing feature. (#18693)

What this is not:

This is not about configuration option FirewallPorts PORTS / ReachableAddresses IP[/MASK][:PORT]… / FascistFirewall 0|1. This is not about the user’s local firewall which restricts things without the user wanting the restriction. This is a feature for users who choose to add additional restrictions for themselves.

Can we make this a sound request that does not sound as if it would only be useful for Whonix? This is to higher chances that Tor Project would implement this feature.

Please post enhanced drafts.

---

[1] Tor is a censorship circumvention software. Once an application (let’s say Tor Browser, gpg, curl or electrum is talking to a Tor SocksPort it is talking to a censorship circumvention software, Tor, and all bets (any iptables/firewall/Whonix power over it) are off. Tor then forwards the request through the Tor network to a Tor exit relay.

Should the Tor exit relays censor any connections to any IPs (perhaps only if not listed in the Tor relay’s exit policy), it would be eventually removed from Tor census by Tor directory authorities. So filtering by destination IP is not yet supported by Tor. Tor exit relays can restrict which ports they like to forward but last time I checked there is always some exit relay that allows any port, so Tor is also great to get around port restrictions.

Tor does not have any options to restrict which destination IPs and ports it can reach. This is mentioned in above draft.

//cc @xariv

[xariv]

Not sure if it can be part of this request or not, but essentially this system should also not allow non-whitelisted onion sites too. Onion sites are the perfect place to host malware. So much, that they are used for this purpose even for targets that don’t have tor, via tor2web.

[Patrick]

Onion whitelist fits well into this request. Just now edited the draft.

[HulaHoop]

@Patrick

Onion whitelist fits well into this request. Just now edited the draft.

FYI can be done indirectly with IPTables and the MapAddress Tor feature:

Block all traffic except some hidden addresses

Interesting, there might be a way to do this. Drop all incoming/outgoing traffic. Make an exception for a local-only subnet range say 192.168 Use MapAddress to assign private addresses in the whitelisted range to the Onion Services you want to permit. Some steps that can help: