In-/Outbound firewall configuration for Tor relay

In-/Outbound firewall configuration for Tor relay

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

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.

Since this enlarges the ruleset (already quite complex here :-| ),
I am wondering if there is a more simple way to achieve this.

(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?

Thanks, and best regards,
Peter Müller
-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: In-/Outbound firewall configuration for Tor relay

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

On Wed, 2018-06-27 at 22:53 +0200, Peter Müller 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.

> 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.

> (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.

Best,
- -Michael

> 
> Thanks, and best regards,
> Peter Müller
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls005wACgkQgHnw/2+Q
CQe2QhAAryeVSpqKc5mJpMhlUE/LwnGGSJbn+eRfd/Buy6NXqPO2LXrh4H7ljr6D
z3Q1N6h7Yc5J1bjRqxeYALl9kMpnudoPej0k600v2FwGxSqQaSEeriHSHkF63UK1
24zTf5ExjdmVqy9TGsjou1qgeg5XkxeG631vqBzay19Ts0zhA6RJmviCVJIxfMup
ypg94t6hHgTTEqdPUo95gXRkkE7fkW0ZpBymDR5SUXuLu+Y7QCIPhvEoD2ttk3lt
NVOKLmZkaK6VRzPk/ONT5Ia+xsO0zDIoe6Uf2D25Y7B4G7izCDJNNWyxe66ezkmU
ji17aK/4rc3LvBl6zPNBO9SkCfHxy31HyguWoEBTBH4a8ytY3oGPW7KLZQw2ERxH
nhQvC6vSEL86n4Q0BVf6xVEtaZITxLNiOVkBWEigdYY2FFJbCvrs0g6d/OG+VVWN
Y9Ab9K8RVWD16qRoXoPf1SDOlpxhOSghVFW1y3ExSd7k+vdCgzYO+APIjEQAHSrE
H63VZdJB14wieBEUDizYqb857OdUsNi4J91DevCZGQOsRDftzZCTXeVoV1pgcUbc
ig81DFD0d6b1/1fZiQ0GQyy3vXl2h8NRAl+NZnfAMezZx5HyGcGAVRCS4siA+w0w
NbSChIef8zY3+ke8Cm2MA6jO5fs7Xdf0eU99LPZEeDU4mQFOGxQ=
=6Aha
-----END PGP SIGNATURE-----

Re: In-/Outbound firewall configuration for Tor relay

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

Hello Michael,

thanks for the clarification.

> Hello,
> 
> On Wed, 2018-06-27 at 22:53 +0200, Peter Müller 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.

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.jpg),
it is processed before anything else, so this would suit.

Will test this and get back if problems occur.
> 
Best regards,
Peter Müller
-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: In-/Outbound firewall configuration for Tor relay

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3717 bytes --]

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üller

Am 28.06.2018 um 19:14 schrieb Peter Müller:
> Hello Michael,
> 
> thanks for the clarification.
> 
>> Hello,
>>
>> On Wed, 2018-06-27 at 22:53 +0200, Peter Müller 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.
> 
> 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.jpg),
> it is processed before anything else, so this would suit.
> 
> Will test this and get back if problems occur.
>>
> Best regards,
> Peter Müller
> 

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: In-/Outbound firewall configuration for Tor relay

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 5324 bytes --]

Hello Michael,

> On Fri, 2018-06-29 at 23:26 +0200, Peter Müller wrote:
>> 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.
> 
> 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?
> 
>> (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.
> 
> 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.local .
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 allowed
(which I _strongly_ advise against), this is not a pity since inbound connections
can be handled even by using the WebUI.

Best regards,
Peter Müller
> 
>> 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?
> 
> Not that I am aware of.
> 
> -Michael
> 
> 
>> Best regards,
>> Peter Müller
> 
>> Am 28.06.2018 um 19:14 schrieb Peter Müller:
>>> Hello Michael,
>>>
>>> thanks for the clarification.
>>>
>>>> Hello,
>>>>
>>>> On Wed, 2018-06-27 at 22:53 +0200, Peter Müller 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.
>>>
>>> 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.jpg)
>>> ,
>>> it is processed before anything else, so this would suit.
>>>
>>> Will test this and get back if problems occur.
>>>>
>>>
>>> Best regards,
>>> Peter Müller
>>>
> 
> 
> 

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: In-/Outbound firewall configuration for Tor relay

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6939 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sun, 2018-07-01 at 08:00 +0200, Peter Müller wrote:
> Hello Michael,
> 
> > On Fri, 2018-06-29 at 23:26 +0200, Peter Müller wrote:
> > > 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.
> > 
> > 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?

Yes, useradd isn't very well configured and does (or did) not support system
users and all this stuff. You can give it a try.

> > 
> > > (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.
> > 
> > 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.local .
> During boot sequence, things are loaded the other way round, so the PID
> cannot be determined. A dedicated user would help here a lot.

Agreed.

> 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
> allowed
> (which I _strongly_ advise against), this is not a pity since inbound
> connections
> can be handled even by using the WebUI.
> 
> Best regards,
> Peter Müller
> > 
> > > 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?
> > 
> > Not that I am aware of.
> > 
> > -Michael
> > 
> > 
> > > Best regards,
> > > Peter Müller
> > > Am 28.06.2018 um 19:14 schrieb Peter Müller:
> > > > Hello Michael,
> > > > 
> > > > thanks for the clarification.
> > > > 
> > > > > Hello,
> > > > > 
> > > > > On Wed, 2018-06-27 at 22:53 +0200, Peter Müller 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.
> > > > 
> > > > 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.
> > > > jpg)
> > > > ,
> > > > it is processed before anything else, so this would suit.
> > > > 
> > > > Will test this and get back if problems occur.
> > > > > 
> > > > 
> > > > Best regards,
> > > > Peter Müller
> > > > 
> > 
> > 
> > 
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls4oVkACgkQgHnw/2+Q
CQf5KxAAg270VjY7AG/yiV8O8auIVePrpaQ74EfbpYIRUHBWH7uPqF7Ag4TB40Ho
CCqdP6mowePfTjmgM6UDU9vry3Pu0hh/L+gKHtw3cNh2TZJGfNDjeCvcG+kMV8oA
j945kk1awse34XDgiJh8wpemvNzpIqKIRJFJvo8VdKhI6d1IeIgA3VWhJjv/31lU
cl8J4WJW9dVy750eM7oHRMxE6RY8TvDnQHP1CYCRBwwH21jN9rHyIU55zJbCkm6N
i4acEyUD6IiYUslHEudp6Sa5UzCrSnuVb/cNn3xUnjmwUyRfTJkXg1ypWgn/IV9N
PTg+G/QkNYrC2CH2LtIKnTguTF026OZzCfAhkpoLdUsdNG/W4R/1iANr6QzuDZz7
4jHi6F6ujEontoRKecXxIq0lbv21bHM8kKGS8lXDUZSafX9ku0ALzRCCJcvMygOJ
k3RN3iyMQg5PEIDJ9sOt8eBoYS22TNTYbgJShesI+WR9srv2pNWjdM8q7gXC4UmU
Giu4//MN2R/f5R0WpSPzTzEved01j+cGcKSDacAdRwACNlRXY3utNE0MCKF4KXo5
NmUmbM+XFIpAP5qGjvpa65tHfOeI9rZAIjdbVsd0RNEuhwVrKENfKN09pt6Pz87Z
sPciMueAK056cAPrJd63HIoUxaxIVPpEyvqk5tiSCUFagB8YtEQ=
=17qc
-----END PGP SIGNATURE-----