On Thu, Aug 15, 2013 at 1:05 AM, Philip Guenther <guent...@sendmail.com> wrote:
> [Caveat: I don't hack the network stack. That said...]
>
> On Wed, 14 Aug 2013, Maxim Khitrov wrote:
>> That's exactly the behavior that I wanted. Here are some (untested)
>> examples:
>
> Your examples obfuscated to me. If you want to limit it to stuff to/from
> this box, or not, SAY SO.
pass in proto udp from port bootpc to port bootps user root
This is a separate example, but I thought that this was an elegant and
not at all obfuscated way of handling DHCP traffic. Replacing "user
root" with "to self" doesn't work here, because you also need the
limited broadcast and possibly self:broadcast to handle the wide range
of client behavior that I've seen. And no, I don't want this rule
matching DHCP traffic that wouldn't be delivered to the local socket.
This rule with "user root", if it worked as described, would check two
conditions:
1. Is the firewall the final destination (be it unicast or broadcast)?
2. Is there a local socket owned by root that would accept this traffic?
Saying "to self" isn't the same as checking that the connection would
actually be accepted. I can easily imagine a scenario where I'd want a
rule skipped because the socket is closed, and instead, redirect the
traffic to another server with a subsequent rdr-to rule:
# Handle http traffic with the local server
pass in quick proto tcp to port http user root
# Redirect to backup server if the local server is down
pass in quick proto tcp to (self) port http rdr-to $backup_server
pass out quick proto tcp to $backup_server port http user unknown
Here I'm saying exactly what I mean, no indirection involved. I think
"user" and "group" are a good idea and have their uses, but they need
to work as described. As far as I can tell, even the example in the
man page is wrong:
block out proto { tcp, udp } all
pass out proto { tcp, udp } all user { < 1000, dhartmei }
If "user" is ignored unless there is a local socket, then this would
allow all forwarded traffic to go out (assuming there is also a "pass
in" rule somewhere). Doesn't that seem like a security problem?
