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: Sun, 01 Jul 2018 08:00:17 +0200 Message-ID: <4d83263e-ca97-701e-be4e-4788bd4e482e@link38.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7202229040542471975==" List-Id: --===============7202229040542471975== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > On Fri, 2018-06-29 at 23:26 +0200, Peter M=C3=BCller wrote: >> Hello, >=20 >> while incoming firewall rules seem to work by now, there are still >> some issues with outgoing traffic: >=20 >> (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. >=20 > Everything that is non-privileged runs as this. In IPFire 3 everything has = its > own user. Is there a technical reason why we did not split this up into several users in 2.x as well? How much work would it be to change this for 2.x too? >=20 >> (b) Filtering by PID seems the only way, but creates error messages: >=20 >> iptables v1.4.21: unknown option "--pid-owner" >> Try `iptables -h' or 'iptables --help' for more information. >=20 > Did you try the updated iptables that you submitted this week? Not yet. It might be possible that "--pid-owner" is implemented there, as it does not appear in the documentation for 1.4.x . Either way, filtering by PID has some disadvantages: (a) Every time a process changes its PID, we need to reload firewall.local. (What do we do with forks anyway?) Since PIDs may not be unique on Linux systems, some other program could obtain these network privileges. (b) The initscript of Tor needs to be patched in order to reload firewall.loc= al . During boot sequence, things are loaded the other way round, so the PID cannot be determined. A dedicated user would help here a lot. At the moment, running a relay on an ARM board in the local DMZ seems to be a more elegant way. However, on systems with any outbound connection allow= ed (which I _strongly_ advise against), this is not a pity since inbound connect= ions can be handled even by using the WebUI. Best regards, Peter M=C3=BCller >=20 >> In firewall.local, this rule is currently placed: >=20 >> iptables -A CUSTOMOUTPUT -o ppp0 -m owner --pid-owner $TORPID -p tcp -d >> 0.0.0.0/0 -j ACCEPT >=20 >> 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? >=20 > Not that I am aware of. >=20 > -Michael >=20 >=20 >> Best regards, >> Peter M=C3=BCller >=20 >> Am 28.06.2018 um 19:14 schrieb Peter M=C3=BCller: >>> Hello Michael, >>> >>> thanks for the clarification. >>> >>>> 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 th= at >>>> 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 intention= al >>> in order not to puzzle users. >>> >>> 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 >>>> iptables 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... >>> >>> 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.j= pg) >>> , >>> it is processed before anything else, so this would suit. >>> >>> Will test this and get back if problems occur. >>>> >>> >>> Best regards, >>> Peter M=C3=BCller >>> >=20 >=20 >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============7202229040542471975== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzNGJmRUFDZ2tRMlVqeUQzMTcKbjJoalNBLy9SR0s1TW1Dc1ox cTN0UFdwQjJFVEVsaEVPTDFYUzdmNHNqK2toQjJiWlA4SmtDb3ZGbklBQWRaVQp2WG1qMXBIQkpC ZTkrQmQ0K2QrbzU5WXVjRy9wbVNWOUd3YU9weTJqVmZDN3JFT2h1emVsVEtyZ0VPV3BXTERXCjJ1 VitUYk1WSDdlTnpIZHp4RmU5UWNZL3ZrRHNpdWF5YUJkUmdTdWE0am5YSWRublV5UHZIRFdNZXRB eVlTZDEKT0NoMkFEeVdNSTZhY3BRQTlOeGZoak5kb25KRnl3L2pZNEJObHdKRG4rT2dENVlWMnZh ZXNmRWZvNDFBU3A1WAppWVd3NUZNcEhhZGhEZzVXUWJVT1pjeFgwMnorK1VmVFpSTmVtc1VXZEQv cmNmWVd6UlgwR3hyOU1ZTWxvejBWCjd5d3c5MEE4ZVZzclhyNTdUWkZDNURlS216NG9NWCt0TUJv UTMxMDI3cXk0MUtyeGNka2h4SW5yTG1kZDhWdFkKdUQvcHZlekpiVEtMMnJtQ0xOTDg5dWpJSHNL MysvSVF1SkpjY0NJcE9lV0ZldkloZzBGOEQyY09UWGNKRHJhbQpuOW12dzY0a25TblBJeGxpdFNV SlF0anh6ZDFkWWtDWWRvUDFHdmpBYkNLN0N2OXhESkFZMk1Ed0dHemVrOExlCmV1Z2lnN2Y3Q2N5 U25Gc1VDNmI0SHRMRFlNUm1LV0N2dG5WWEQ3NkgwTGxqY0pNOXZGR0VYR1RSL2hiU04zZjMKc1Ew dExZdGN4SlRtVHVIQllMeGNabXBFOEVRR042ZFhvTkZiRGc5S3hzZmtNeUljblpUVEhGbmlGTnhw WlF4RgpZdVE0RFphKzE3Q3c2cHFaS0pCRGlRTnFJeFgxS3R0cndzbmVHMlNmRmpKbEYwWnNGbHM9 Cj03WVFQCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============7202229040542471975==--