From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: In-/Outbound firewall configuration for Tor relay Date: Fri, 29 Jun 2018 23:26:50 +0200 Message-ID: <8a0fb4d3-20b2-43d1-5f8e-38f40c67efd0@link38.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8936149752390819644==" List-Id: --===============8936149752390819644== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, while incoming firewall rules seem to work by now, there are still some issues with outgoing traffic: (a) Since tor runs as "nobody" (why?), allowing traffic from this user is out of questions because also untrusted services like Apache occupy this user. (b) Filtering by PID seems the only way, but creates error messages: iptables v1.4.21: unknown option "--pid-owner" Try `iptables -h' or 'iptables --help' for more information. In firewall.local, this rule is currently placed: iptables -A CUSTOMOUTPUT -o ppp0 -m owner --pid-owner $TORPID -p tcp -d 0.0.0= .0/0 -j ACCEPT Besides from making things more easy in the future (development ;-) ), is "--pid-owner" even supported by iptables running here? Or does it require some special module? Best regards, Peter M=C3=BCller Am 28.06.2018 um 19:14 schrieb Peter M=C3=BCller: > Hello Michael, >=20 > thanks for the clarification. >=20 >> Hello, >> >> On Wed, 2018-06-27 at 22:53 +0200, Peter M=C3=BCller wrote: >>> Hello, >> >>> for quite some time, IPFire includes Tor via Pakfire as an add-on. >> >>> Trying to set up a Tor relay there, I stumbled into several problems >>> regarding firewall rule configuration: >> >>> (a) Inbound >>> It turns out that Tor is not working correctly if GeoIP block is >>> active (this occurred after a reboot - strange). Of course, one >>> possibility is to disable GeoIP block at all, allow access to the >>> Tor relay ports, and deny any except those of legitimate countries >>> to other services on the firewall machine. >> >> You can use the normal firewall rules for a more granular configuration. >> >> The geoip filter comes first and then all the rest. Depending on how many >> countries you block here, Tor connectivity becomes a little bit useless. > Indeed. And I block many... :-) >> >>> Since this enlarges the ruleset (already quite complex here :-| ), >>> I am wondering if there is a more simple way to achieve this. >> >> We could move tor rules before the GeoIP filter, but I am not sure if that= is >> very intuitive. > I do not think so since users may expect anything is blocked then and > wonder why Tor still works fine. We should keep firewall things intentional > in order not to puzzle users. >=20 > OK, incoming way is solved then. >> >>> (b) Outbound >>> For security reasons (surprise!), outgoing connections are heavily >>> limited here - only DNS, NTP and web traffic is allowed, and only >>> to a certain list of countries. Some call that "racist routing"... >> >>> This does not work with Tor since it needs to open connections to >>> almost any port on almost any IP address. Allowing outbound traffic >>> in general is out of question, so there seems to possibility left. >> >>> Besides from running a Tor relay in the local DMZ and apply the >>> firewall rules for this machine, is there another way? >> >> Not that I am aware of. >> >> You can build something custom here by using the -m owner module of iptabl= es and >> make an exception in the OUTPUT chain for the tor process. You just need a >> little script that puts the pid into it if you cannot check by uid. > Hm, I never used the "owner" module before... >=20 > I guess these custom firewall will need to be placed in "firewall.local" > (https://wiki.ipfire.org/configuration/firewall/firewall.local)? According > to the firewall processing scheme > (https://wiki.ipfire.org/_media/configuration/firewall/ipfire_fw_chains.jpg= ), > it is processed before anything else, so this would suit. >=20 > Will test this and get back if problems occur. >> > Best regards, > Peter M=C3=BCller >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============8936149752390819644== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzMnBCb0FDZ2tRMlVqeUQzMTcKbjJqTWhCQUFraC8rM2h1VFhN aU9ERWw3OFFJOG9PWmt1VXVvT3ZJMFQ0aWFqM1RwUzQzYzVtMUtneTkrM05HTApEZ2d3dUJXU3ZV a0x3bHlXL0Z4ZDd1NjVRbGdkQWh0cHJWdjF3YzkrN08veHRyM291cHFlL0pWd1V5RnF3ZEVQCk9Z VXZnZUd1TGdkMzRMS1FiRXZMNHJ0NlUvQ3RoWnBUZFZWZ0xBRExqbXM3Nm1qVWcvdGN3LzdHbk1S RncvZFoKU1hGZW9EbFlnY1JpQzFQUDZtYVhiN3lMblR5WTJLZGU0QTZMWjMrYWlJamtwU00yRHQ1 eHQ4TlZuVFVUa1dRYQpxU3V0a0o5bU14akxpY2ZERHJHWVNOSVVNVkJNa0VNd09ibSs5S21OTnlW SmhCTzR2L3JDbFBXTkNlemdwU0JzCjZhY0U1azdxYVFESTcwaDBqZlc3d3JUUG05Wmc5YmhyUUJN VXRNWE02bGgzVUp6MTBPSytwSklPSGk2Q1AweTgKTE1QVlJrRGhEWUJidTBuYUFlQVZERUZDN0RO K2c2bUJvSnp0eGRpWUJVMVovRzl4U1dnbHYvc3ZaTzlwZU5aWgphVHJURUU0Wm40czBleEd0OTdM a2YweFJPOFN0aVhDVWVMNjFXaEYrQUZodnRzcHFSWlk1SmQ2NksvSVJHSDM0Cisvb3FYNDMvdUQx VWtMK2x1Y1JDRGx2ejRWOE4rYjByN3orRWRKUU1CdldkblpXNWQ2MEEvYng3MG1JR1JkR2sKS3FZ bjc4emNmU0lINys4TkFOenpYWkppNmJvTnJOTndMMDM5U3dpTTlHSVlQcU42aU5SZUhYUXZGRVZW aEJiWgpVbGJCUmlza3U4ai91dDc5Sm1CenhpY2kwaFAyOWVEQjVjN0FEdWkyMW1adURMOUZ4VzA9 Cj1vcm81Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============8936149752390819644==--