[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.


#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/ ?


#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.