DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
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.
Code:
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:
Code:
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.
Quote:
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.

Quote:
Can you tell me why this

Code:
pass log from any to any
is not the same as

Code:
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 127.0.0.1 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
Old 16th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 124
Default

wow thanks alot for the explanation

i am now trying to foward non pfauth authenticated users to port 80 running on the local host.

I have these in my pf.conf but still it does not work. (httpd is working verified with lynx localhost) To verify this i had to open the pf completely up.


in my pf.conf I have
Code:
match in log on $WRLS_IF proto tcp from ! <authpf_users> port 80 rdr-to 127.0.0.1

pass in log proto tcp from 10.2.0.0/24 to 10.2.0.5 port 80
If i connect to wireless but no ssh it times out.
If i type 10.2.0.5 it comes up with a generic openbsd "it worked" page
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Above, I'd recommended (guidance 3) that you document rules to make it easier to see errors. A comment above the rule that said:
Code:
# allow the authorized client to access servers
would be as I believe you intend, and the correction I recommended above should work. However, a different comment such as:
Code:
# allow clients to reach the authorized server
would have been a different error. My recommendation would have been to correct the in directive.

Documentation helps. It really, really helps. Especially when you're reading your own rulesets after leaving them be for a couple of years.
Reply With Quote
Old 16th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 124
Default

I actually am commenting in my real pf.conf. I will start including the comments here.

What I am actually trying to do is forward non authenticated users "! <authpf_users>" to the web page no matter what website they choose (if they are not authenticated)
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by EverydayDiesel View Post
wow thanks alot for the explanation

i am now trying to foward non pfauth authenticated users to port 80 running on the local host.
I can't tell from the fragment what's being blocked. You can, if you use log in your rules and use tcpdump to watch the blocks/passes.

However, I will point you to the Traffic Redirection chapter of the PF Users Guide for further .. guidance. Note that rdr-to, like nat-to, matches with an assigned interface. So if you use it, you should use "on <interface>".

I use rdr-to, but typically with pass rules, rather than match.
Reply With Quote
Old 16th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 124
Default

I see the pass in and the redirection to 127.0.0.1:80 and then i see a whole bunch of dns blocks to 4.4.4.4:53.

i guess the question is, is the dns blocking the connection from even happening how do i resolve the dns www.whatever.com to be forwarded to 127.0.0.1?
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Here's an example of a real rdr-to from one of my firewalls. There is a pass inbound, with redirection, and also an outbound pass. These are separate, because the rule matching the inbound traffic is not the same as the outbound traffic, so two rules are used.

I also include https (destination port 443) which you have not yet considered for your ruleset so far.
Code:
# redirect web and ident services to the MASTER server:
#
pass in log quick on $external_nic proto tcp from any to any \
        port {www https ident} rdr-to $master
pass out log quick proto tcp from any to $master port {www https ident}
----
Edited to add: The rdr-to needs an "on <interface>", which is really why there are two rules -- the second rule permits the traffic to pass on other interfaces. The "in" and "out" are active, but are really there as documentation for me, more than for any effect.

Last edited by jggimi; 16th July 2014 at 03:57 AM. Reason: fixed a thinko. and a typo. Then added more explanation.
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by EverydayDiesel View Post
i guess the question is, is the dns blocking the connection from even happening
Yes.
Quote:

how do i resolve the dns www.whatever.com to be forwarded to 127.0.0.1?
Pass DNS traffic. When the client obtains an IP address, only then will it reach out to port 80 at the destination server. Which your rdr-to will redirect for you.
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

If you're ever concerned about unauthorized traffic getting past your firewall using the domain name resolution destination ports (UDP 53, TCP 53), you have some choices. You could:
  • Only pass traffic to your selected nameservers.
  • Redirect the traffic to your selected nameservers.
  • Redirect the traffic to your own nameserver, and resolve names to addresses of your own desire.

Last edited by jggimi; 16th July 2014 at 12:09 PM. Reason: typos. Always typos.
Reply With Quote
Old 16th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 124
Default

Quote:
Originally Posted by jggimi View Post
If you're ever concerned about unauthorized traffic getting past your firewall using the domain name resolution destination ports (UDP 53, TCP 53), you have some choices. You could:
  • Only pass traffic to your selected nameservers.
  • Redirect the traffic to your selected nameservers.
  • Redirect the traffic to your own nameserver, and resolve names to addresses of your own desire.
I like these ideas alot. I have been wanting to learn BIND for local dns.

Can I configure bind to play nice with authpf? If the user is authenticated cache the nslookup (of it not, look it up from 4.4.4.4). If the user has not authenticated then route them to some kind of dummy dns?
Reply With Quote
Old 16th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by EverydayDiesel View Post
I have been wanting to learn BIND for local dns.
You could use BIND, but there are replacements which may be easier to configure, maintain, manage, and use. One of those is unbound(8), a caching DNS resolver which moved from ports to the base OS in -current (and the upcoming 5.6) in March. If you're running -release/-stable, unbound is in ports. Michael Lucas has a brief howto on his blog.
Quote:
Can I configure bind to play nice with authpf? If the user is authenticated cache the nslookup (of it not, look it up from 4.4.4.4).
Certainly.
Quote:
If the user has not authenticated then route them to some kind of dummy dns?
I wouldn't do this. The client's local resolver may keep using your fake addresses after the client completes authentication. Just use rdr-to, and for applicable traffic, divert-to.

A PF-based solution will not cause problems for an eventually authorized client.

Last edited by jggimi; 16th July 2014 at 03:41 PM. Reason: typos. typos. typos. typos. topys.
Reply With Quote
Reply

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 04:47 PM.


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