On Wed, Aug 14, 2013 at 3:14 PM, Mike Belopuhov <m...@belopuhov.com> wrote: > On 14 August 2013 20:34, Maxim Khitrov <m...@mxcrypt.com> wrote: >> Hello, >> >> I expected the following rule to only match traffic destined for the >> firewall: >> >> pass in proto tcp to port ssh user root >> >> Likewise, by changing "root" to "unknown" I expected to only match >> traffic that is to be forwarded to other ssh servers. Both turned out >> to be wrong assumptions. >> >> I think that because sshd listens on *:22, pf considers all traffic to >> port 22 as matching "user root" criteria, even if the firewall is not >> the final destination. This behavior doesn't match the man page: >> >> "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'm inclined to think that this is a bug in the code, since otherwise >> user and group criteria are not very useful at distinguishing where >> the traffic is going. >> >> - Max >> > > unless a local socket is found, user or group check will not be performed.
That doesn't make sense to me. Are you saying that a user/group condition is ignored in some cases? That sounds like a bug in itself. If it's there, then it has to be satisfied or the rule doesn't match. In my case, I had "user root" matching traffic not destined for the firewall. Whether that's because the check was silently skipped or because sshd on *:22 caused it to be successful, pf is still behaving in a very unexpected and undocumented way. How would "user unknown" work? If the firewall isn't an endpoint, then there is no local socket. Furthermore, isn't a user/group condition what prompts pf to go looking for a local socket? How can you not perform this check after performing it?
