Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
Join Date: May 2008
Location: USA
Posts: 6,455

Originally Posted by EverydayDiesel View Post
I am running the SSH daemon and the HTTPD daemon on the same box (its a box that just does wireless connections)
Let's look at the highlighted rule more closely.
pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT
The directive in. This is from the point of view of the platform running PF. So, this will pass packets coming inbound towards the PF platform.

The directive on. This rule applies only to inbound packets on the PF platform's athn0 interface, the innermost network (though PF doesn't know or care about that).

The directive from. This rule applies to inbound packets on the athn0 interface from any possible address.

The problem directive to. This rule applies to inbound packets on the athn0 from any address yet destined for the IP address of the authorized client, $user_ip. You are unlikely to match any traffic with this directive, for two reasons: a) The destination is your client, but the traffic is inbound, not outbound, and b) the defined ports are destination port numbers, used by servers to "listen" for requests -- your client isn't listening for service requests on these ports.

When you write a rule with port numbers, the rule uses this formal syntax, per the pf.conf(5) man page:
from <source> port <source> os <source> to <dest> port <dest>
If you leave one of these undefined, the rule will interpret this as any. And we usually leave our source ports undefined (any), because they are usually high numbered and random, for most of the common UDP and TCP services.
is this still what i want?

pass in proto tcp from $user_ip to any port $TCP_PORT
I believe so, because you want your client to use its random, high numbered source port with any server listining on destination ports 22 and 80. If you want to restrict the client to use only your ssh and webserver on the one platform, change the "any" to the address of the server that provides the services.

Can you tell me why this

pass log from any to any
is not the same as

pass out log on xl0 from any to any
pass in log on xl0 from any to any

pass in log on authn0 from any to any
pass out log on authn0 from any to any
You mean beyond readability? Your second rule fragment is focused on two interfaces (one is misspelled) and your system has one more NIC that will have IP traffic -- the pseudo-NIC lo0, for loopback traffic, using the address on the large CIDR netblock 127/8. The first single-line rule will pass this traffic, the second ruleset doesn't consider it, and it will depend on other pass or block rules (or set skip) how that traffic will be treated.

All of the "from any to any" directives can be left out, this is the default for pass, block, and match rules. You can leave the in and out directives off also, and reduce your rule count.

Last edited by jggimi; 16th July 2014 at 02:57 AM. Reason: typos. again. and always.
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Wireless Setup With AuthPF Help EverydayDiesel OpenBSD Security 3 2nd July 2014 11:38 PM
authpf setup dbach OpenBSD General 14 19th January 2013 04:25 AM
authpf, authpf.rules unable to modify filters kbeaucha OpenBSD Security 16 10th May 2012 09:46 PM
transparent firewall & authpf? ll2ollvll3o OpenBSD General 2 10th April 2012 12:42 AM
Exempting clients from AuthPF Kristijan NetBSD Security 1 12th July 2008 12:09 AM

All times are GMT. The time now is 01:54 PM.

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick