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

Traffic monitoring and better control

#1

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.

#2

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



#3

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.

1 Like
#4

I believe you can use iptables for such whitelisting.

#5

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

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.

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.

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

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

usability, popularity vs security, Freedom Software purism
#6

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

#7

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

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.

#8

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

#9

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.

1 Like
#10

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

#11

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