On Thu, Dec 19, 2013 at 7:57 AM, Giancarlo Razzolini
<grazzol...@gmail.com> wrote:
> Em 18-12-2013 21:33, Andy Lemin escreveu:
>> Fantastic! Thanks Camiel :)
>>
>> Sent from my iPhone
>>
>>> On 18 Dec 2013, at 21:32, Camiel Dobbelaar <c...@sentia.nl> wrote:
>>>
>>>> On 18/12/13 14:50, Maxim Khitrov wrote:
>>>>> On Wed, Dec 18, 2013 at 8:42 AM, Camiel Dobbelaar <c...@sentia.nl> wrote:
>>>>>> On 18/12/13 13:53, Maxim Khitrov wrote:
>>>>>>
>>>>>> When writing outbound rules in pf, is there an accepted best practice
>>>>>> for only matching packets that are either forwarded or
>>>>>> firewall-generated?
>>>>>>
>>>>>> The best that I could come up with is 'received-on all' as a way of
>>>>>> identifying forwarded packets, but that option can't be negated to
>>>>>> match packets that were not received on any inbound interface (i.e.
>>>>>> those generated by the firewall itself).
>>>>>>
>>>>>> Another option is 'from (self)', but then you have to be careful with
>>>>>> any preceding nat rules. Ideally, I want a solution that doesn't
>>>>>> depend on the context. I also tried to use tags in combination with
>>>>>> 'received-on', but it became rather messy and created conflicts with
>>>>>> other tag usage.
>>>>>>
>>>>>> What is everyone else using to solve this problem?
>>>>>
>>>>> Check the "user" option in pf.conf(5):
>>>>>
>>>>> user <user>
>>>>> This rule only applies to packets of sockets owned by the
>>>>> specified user. For outgoing connections initiated from the
>>>>> firewall, this is the user that opened the connection. For
>>>>> incoming connections to the firewall itself, this is the user
>>>>> that listens on the destination port. For forwarded
>>>>> connections,
>>>>> where the firewall is not a connection endpoint, the user and
>>>>> group are unknown.
>>>> I tried that a while ago and it doesn't work as documented:
>>>>
>>>> http://marc.info/?l=openbsd-bugs&m=137650531124231&w=2
>>>> http://marc.info/?l=openbsd-bugs&m=137658379014570&w=2
>>> Nice of you to lure me in like this, and spent a few hours looking at the
>>> code. :-)
>>>
>>> I'd say the feature is indeed broken, and probably has been for more then
>>> 10 years.
>>>
>>> in_pcblookup_listen() in pf.c is the culprit. The destination IP does not
>>> seem to matter for the socket lookup and will match anything. As you
>>> noticed, this makes forwarded traffic match too.
>>>
>>> So I guess the only way to make this work at all is to match the source and
>>> destination IP's yourself first in pf.conf like this:
>>>
>>> pass in from any to self port 22 user root
>>> pass out from self to any user camield
>>>
>>> Regards,
>>> Cam
> There are so many ways to do this. self rules, user, etc. But I'd say
> that you could also use tags to do policy based matching of packets that
> are firewall generated or firewall forwarded. Tags can be assigned
> before any nat matching rules take place, so you do not need to worry
> with them messing up your packet flow.
That's pretty much what I managed to come up with yesterday. I have
the following two rules at the top:
match out from (self) tag SELF
block out log quick received-on all tagged SELF
The second rule is mostly a sanity check. It ensures that you can't
accidentally add a SELF tag to an inbound packet and have it processed
as a firewall-generated packet. These are followed by a few rules
common to forwarded and firewall-generated packets. Finally, I split
the ruleset like so:
anchor out quick tagged SELF {
block return log
# Rules for firewall-generated traffic
...
}
# Rules for forwarded traffic
...
This seems like a good enough solution, but it would be cleaner if we
could do '!received-on all'. There is also a risk here that one of the
preceding rules could overwrite the SELF tag.
