Patrick Schleizer:
> anonym:
>> https://tails.boum.org/news/report_2016_09/#index2h1
>>
>> and look at the documentation at the top of the script, and the filter
>> rules we ship to get an idea of what it can do.
>
>> As you can see, in Tails we use match-exe-paths and match-users a lot,
>> but since you won't have access to these I guess you want something like
>> match-hosts, so that the filter is picked based on the client's
>> (non-localhost) address (= VM). Right?
>
> The match-hosts works well for Whonix. Set to "*" for now.
See my other answer why you perhaps want to give this another quick thought.
>>> add_onion is not a whitelist/not whitelist.
>>
>> I do not understand this sentence...
>
> Originally we at Whonix thought we wanted "wildcard support". Meant,
> matching just "add_onion *", i.e. letting everything through
> that comes after "add_onion". As it turned out, that was insufficient.
> For example, add_onion flag "nonanonymous" ought to be avoided.
Got it!
> Tails control port filter proxy seems to keep care of that.
Regexes > globs! :)
>>>>> - https://phabricator.whonix.org/T564
>>>
>>> Protecting cpfpy from DDOS from client applications. Not sure that
>>> matters for Tails?
>>
>> We do not do much specific here. What kind of DoS are you talking about
>> here? Eating up all RAM or crashing the filter via oom kill? Preventing
>> the filter from serving other clients? We admittedly do not do much here
>> except that each client is dealt with in a separate thread, and that
>> client requests are limited to 1024 bytes.
>
> Yes, I meant crashing the filter or making the whole computer unusable
> by flooding cpfpy with too much requests.
So the scenario is something like this: an attacker compromises the
workstation, and then want to crash the filter running on the gateway
(or even crash the whole gateway)? If so, IMHO DoS is the least of our
worries since all gateway activity (= user activity) now is compromised.
I mean, the attacker can DoS the workstation by killing all user
processes or whatever.
... but now I get that you may run several workstations (in Qubes, I
guess), and then this makes sense.
Quick solution that a determined adversary probably easily can work
around: in the gatway's firewall rules, rate limit the traffic to the
control filter per workstation.
Slightly more involved, slightly more efficient solution: we could add
an option to the filter making the server forking instead of threading,
and then adjust OOM scores and NICEness for these subprocesses so they
are low prio for the CPU, and prone to get OOM killed if memory gets
low. The server process itself will be configured in the opposite way
(you can add the options via a systemd override).
Any way, DoS protection is pretty hard... and I doubt it's much of a
problem on *local* systems. Rather DoS gives away that a workstation has
been compromised, instead of it remaining in a stealthy surveillance
mode, which I think I must consider worse (even when limited to a single
workstation == application).
>> I could even imagine yet another rule-type for solving these types of
>> issues:
>>
>> GETINFO:
>> - pattern: 'net/listeners/socks'
>> respond: '250-net/listeners/socks="127.0.0.1:9150"'
>
> Seems great!
In the end, this was generalised into:
GETINFO:
- pattern: 'net/listeners/socks'
response:
- pattern: '250-net/listeners/socks=".*"'
- replacement: '250-net/listeners/socks="127.0.0.1:9150"'
Cheers!
