> > echo 1 > /proc/sys/net/ipv4/tcp_rfc1337 > > not the right option; this is different, and to avoid an issue with time wait. > > the feature i'm thinking of is time-wait negotiation, which can be > tweaked to always put this state on the peer (or fail if not > available). > > last time i messed with this is was kernel build tweaks; probably too > much for most tastes ;) > > > regarding the match rules, why are you whitelisting a firefox > instances? a robust setup is everything transparently routed, except > for Tor PID, and only this PID. kernel originated traffic and all > other application originated traffic is thus routed properly without > bypass, assuming Tor itself is not vulnerable.
coderman, thanks for your persisting interest in my issue. I appreciate it. Unfortunately your sysconf switches don't work for me. That's fine. I think I will simply drop non-uid 42 bytes packets from now on, without explicit logging. (I cannot afford a 72MiB syslog after a few days of computer usage) Regarding my setup, it is not that simple. Actually I have four firefox users and four dedicated tor instances for these users. Each firefox is dedicated to special requirements. I have lots of other users, each for dedicated use cases. All other users, including my main user, do not have internet access at all. This setup-up is loosely based on the setup another Tor user presented on this very list a few years ago. What I fear most is not a breach of my anonymity or the breakage of firefox due to exploitation (geez, browser suck so much these days). I fear the mix-up of application traffic which in turn breaks the anonymity of the application stream that I really want to be anonymous. E.g. I usually have all three browser opened, routing all of their traffic through the same tor instance is madness. _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
