whonix-gateway and iplist? (PeerGuardian/PeerBlock for Linux)

I have long used ipblock (iplist) on Linux, subscribing to a number of ip lists and so ignoring much of the bozos of the net. e.g. Incoming WAN packets in the private address space, bogon ranges, and so on.

– essentially it just adds/maintains rules in iptables.

It has been seamless for me for a very long time.

In essence it is PeerGuardian, now PeerBlock for Linux.

I see there is now an actual PeerGuardian for Linux with a deb repository.

Are there any concerns or howtos surrounding installing it on whonix-gateway?
i.e. Incantations to chant for whonix to permit/integrate it, not on the mechanics of installing the package itself.

I would not use it inside a VM that you also use for browsing. It would mess up your browser fingerprint. ( Network, Browser and Website Fingerprint ) If you separate VMs however, installing this filter on the workstation should be fine. Installing it on the gateway, I don’t know. It could interfere with Whonix-Gateway’s firewall. I would have to look closely how the package actually works to say. Until someone did that, I recommend against installing it on the gateway.

It merely fetches iplists and munges iptables to deny traffic (except that which one whitelists). Assume that for the purposes of this discussion - my investigations to date have proven that (to me), but should it / I detect it behaves differently, I will post a followup.

[quote]I would not use it inside a VM that you also use for browsing.[/quote]I was assuming application at -gateway. (Catch any/all/multiple clients with one install.)

[quote]It would mess up your browser fingerprint. ( Network, Browser and Website Fingerprint )[/quote] How? The browser fingerprint is the browser (machine?) fingerprint. Traffic is either being denied, or permitted - the browser doesn’t know why something is/n’t going through - i.e. gets no response with denied traffic.

Yep. Thus the question. A question inherent to anything that plays with iptables - especially if you have multiple disparate iptables playing pieces, all unaware of each other. Increasing the possibility of tripping over each other.

Mind you … my quick read of the sf site shows that they are now putting their rules into their own chains. So the interaction point is now only (and flow this chain too), not an inadvertent mingling of rules.

Guess I’ll have to play and report back. It seems, though, that the tests should be relatively simple, vs the complex it could be with intermingled rules.

i.e. (a) yes, chains processed packets in sequence without interfering with each other [or not], and (b) the new player didn’t accept a packet with no further examination, passing a packet that whonix by itself wouldn’t have [or not].

If each is confirmed generally, it feels like it is confirmed for all specific cases.

On the surface, it seems simple - (additional) restrictions on traffic, or not, but I take your point that it may not be that simple.

Thanks for your thoughts.

Now if I can only figure out how to install it on the -gateway, e.g. still not sure why apt-get works and not aptitude. Mind you, did now find ssh.anondist-orig, so making progress. Snapshots will be useful.

And I wouldn’t do this for the fingerprinting issues - unless you are using multiple Whonix-Gateways. ( Multiple Whonix-Workstation ™ )

Because your browser will not be able to connect to lots of advertising/tracking websites that run on loads of websites in the background. Therefore you will stand out from other users. You will be the one that probably runs some filter software. That’s more pseudonymous than anonymous. ( Tips on Remaining Anonymous. )

Ah! Thanks for that.

In essence, use of such is making it possible to indeed prove a negative.

Hadn’t thought of that. Thank you!

pgl seems to be OK.

Seems to do exactly what it says to ip_tables - putting its rules in its own chains, and merely pre-pending those chains to everyone else’s. Documentation notes indicate that it delays starting until all other firewalls / ip_tables impacting services have.

It only rejects, based on given rules and block lists, or permits per whitelist (overriding its rules and block lists) - which is to say, permits evaluation to continue through the chains present if it wasn’t, and therefore permitting those chains to themselves reject traffic just as they did prior.

I can see it explicitly permits (doesn’t reject) local interface networks and whonix’s DNS (, out of the box. i.e. By default should not break your environment.

It says it now includes a watchdog to restart upon blockage. (A problem with the Linux iplist project wherein a failure in fetching / processing shuts down all traffic. e.g. A parsing or website down error. Both are supposed to revert to the prior downloaded list in such cases, but a bug in iplist seems to regularly prevent that - leaving you mysteriously unable to communicate at all. [Simply restarting iplist resolves the issue - but you’re mysteriously incommunicado in the mean time.] Appears pgl has taken steps to try to address that.)

Good notes at:
- PeerGuardian / Wiki / pgl-Usage
- PeerGuardian / Wiki / pgl-Technical
- (and) PeerGuardian / Wiki / pgl-FAQ

Add repo to sources.d, e.g. /etc/apt/sources.list.d/pgl.list:
deb Index of /debian wheezy main
deb-src Index of /debian wheezy main

apt-get update ; apt-get install pglcmd pgld pglgui

Appears to do as intended / expected (you’re loading block lists, after all) / does no harm at install.

Be advised: YMMV - every situation is different. Check after install that your particular setup still works - e.g. if you are using non-standard ip’s in your virtual lan, you may find them blocked until you adjust pgl accordingly.

Although I am not specifically endorsing the package, here, I am explicitly not rejecting it. I can say that in my own experience, for my own situation and environment, it works for me. And probably will for you, if you are looking for and understand the nature of (blacklist) ip_tables blocking / management.

NOTE: As Patrick points out … pgl use will likely change your fingerprint - for the things that -aren’t- there vis a vis the rest of the internet. If this is not good / acceptable for your use case - don’t use it. The point of whonix is to keep as large a haystack as possible in which actors have to try and pinpoint a very small needle (you). pgl use will make the size of that haystack smaller. Perhaps much smaller, but personally I don’t expect so - unless your normal activity would make you a target of the most prevalent actors looking for such. (So bloggers, I’m guessing, likely have fewer actors worldwide looking for them.) Even if you thus put yourself in this smaller haystack, they still have to (want to) find you, and the whole point of whonix, or you wouldn’t be using it, or here to read this, is to diminish their ability to uniquely identify, target, and find you.

Mind you - one of the ways they might find you is to attack you (by diminishing your ability to access the internet) or try to infect you (perhaps with something that phones home flagging where you really are), and using such lists and rejecting such traffic will likely diminish the ability to, or efficacy of, such attacks.

Defence in depth may well apply here.

* Note: By default, whonix only permits TCP traffic to TOR. Using pgl can only degrade performance, since all traffic now goes through an additional pass/fail evaluation process. I believe whonix already has defensive measure in place for protection from bad TOR nodes, effected at the next routing change - by default every 10 minutes. If you use pgl, make sure you don’t block your TOR nodes, or you will be unhappy.

* Note: Similarly, if you are using a VPN or proxy, make sure pgl doesn’t block them, or you will be similarly unhappy. It is conceivable that pgl will prevent you from interacting with bad VPN or proxy IPs, but presumably you checked such out before making such settings in the first place.

YMMV. Use at your own risk. But works for me.

No. See:
Frequently Asked Questions - Whonix ™ FAQ

Perhaps I have misphrased. And perhaps I misunderstand.

What I meant (and, agreed, whonix is using torbrowser, and this is a tor/torbrowser only, not whonix, thing) …
er, torbrowser uses tor, and only tor is relevant to this conversation … (?)

If I understand correctly, every 10 minutes, tor changes it’s path through the cloud. Different entry, middle, and/or exit nodes are chosen.

And, over time, good tor nodes will detect and refuse to connect to bad tor nodes.

So, in essence:

I believe whonix already has defensive measure in place for protection from bad TOR nodes, effected at the next routing change

To Patrick’s point … replace ‘whonix’ with ‘tor’, above.


Right. And please make that TOR ->Tor.