DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 6th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default AuthPF Configuration

I am having some issues getting authpf to work on my network.

If I open up putty and log in with this configuration, i type my username and pwd and then immediately the putty window closes.

(By the way ....If I open pf wide open then it the putty window will stay open and I have internet so I know it has to be something with the firewall rules)

/etc/pf.conf
Code:
EXT_IF = "xl0"
WIRELESS_IF = "athn0"

auth_web = "10.1.0.1"

table <authpf_users> persist

block drop log all

match out on $EXT_IF from $WIRELESS_IF:network nat-to ($EXT_IF)

pass out quick on $EXT_IF inet proto { tcp, udp } from $WIRELESS_IF:network
pass in on $WIRELESS_IF inet proto tcp from any to 10.2.0.1 port ssh

anchor "authpf/*"

/etc/authpf/authpf.rules
Code:
WIRELESS_IF = "athn0"

TCP_PORTS = "{ 80 443 ssh }"
UDP_PORTS = "{ 53 }

pass in quick on $WIRELESS_IF proto tcp from $user_ip to any port $TCP_PORTS

pass in quick on $WIRELESS_IF proto udp from $user_ip to any port $UDP_PORTS
Any ideas on what i could be doing wrong here?
Reply With Quote
  #2   (View Single Post)  
Old 6th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

To authenticate authpf, the user must be configured to login with the authpf shell. It is a non-functional shell, other than it can display a message of the day. That means that if you are the user, and you have a standard shell (such as /bin/ksh), you must create another userid for the purpose of authentication with authpf.
Reply With Quote
  #3   (View Single Post)  
Old 6th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

For additional information you may have missed regarding authpf configuration, please review the authpf(8) man page, which describes the two authpf shells in some detail.
Reply With Quote
  #4   (View Single Post)  
Old 6th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

I created 1 user and choose authpf for the type. If I open the firewall it works fin so I think it is something with the rules.
Reply With Quote
  #5   (View Single Post)  
Old 6th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

Use pfctl with -a to inspect active anchor rules. Use tcpdump to discover what rule is matching your traffic.
Reply With Quote
  #6   (View Single Post)  
Old 6th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

Thanks. When I run pfctl -f /etc/pf.conf-a authpf it tells me

Pfctl:warning: namespace collision with <authpf_users> global table.
Reply With Quote
  #7   (View Single Post)  
Old 6th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

Let's go step by step, please.

1. When your user is logged in to the authpf shell, does that user receive this message, "Hello <userid>. You are authenticated from host <ip address>" ? If yes, the authpf shell is active. If not, you have a configuration problem.

2. While that user is logged in, what do you see when you issue this command on the gateway?

# pfctl -sr -a authpf/*

If you don't see rules, or, you see the wrong rules, you have a configuration problem.

3. What message do you get while that user is logged in, when you have tcpdump running on the gateway with the following command, and you try to reach your destination?

# tcpdump -neti pflog0 action block

I want to know what traffic is being blocked.

---

1. This will tell us if you have an authpf shell or not.
2. This will tell us if you have applicable rules enabled through authpf
3. This will show us what traffic got blocked. We know its blocked; we will be able to see what type of traffic it is and determine why it does not match a pass rule.
Reply With Quote
  #8   (View Single Post)  
Old 7th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jggimi View Post
Let's go step by step, please.

1. When your user is logged in to the authpf shell, does that user receive this message, "Hello <userid>. You are authenticated from host <ip address>" ? If yes, the authpf shell is active. If not, you have a configuration problem.
If i add the following lines to /etc/authpf/authpf.rules
Code:
pass in from any to any
Then yes the window will stay open and say you are now authenticated.

Quote:
Originally Posted by jggimi View Post

2. While that user is logged in, what do you see when you issue this command on the gateway?

# pfctl -sr -a authpf/*

If you don't see rules, or, you see the wrong rules, you have a configuration problem.
the pf command returns nothing, just immediately back to the command prompt

Quote:
Originally Posted by jggimi View Post

3. What message do you get while that user is logged in, when you have tcpdump running on the gateway with the following command, and you try to reach your destination?

# tcpdump -neti pflog0 action block

I want to know what traffic is being blocked.

---

1. This will tell us if you have an authpf shell or not.
2. This will tell us if you have applicable rules enabled through authpf
3. This will show us what traffic got blocked. We know its blocked; we will be able to see what type of traffic it is and determine why it does not match a pass rule.
tcpdump doesnt display anything related to the login. I do see blocks in athn0 on port 53

rule 0/(match) block in on athn0: 10.2.0.32.60596 > 4.4.4.4.53: 946+[|domain]

Last edited by EverydayDiesel; 7th July 2014 at 01:22 AM.
Reply With Quote
  #9   (View Single Post)  
Old 7th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

Quote:
Originally Posted by EverydayDiesel View Post
If i add the following lines to /etc/authpf/authpf.rules
Code:
pass in from any to any
Then yes the window will stay open and say you are now authenticated.
1. You have a configuration problem. SSH is being blocked between the end device and the gateway. SSH traffic must pass in order to authenticate. Either your rules are not properly loaded, or you are never reaching traffic with your pass rule for inbound SSH. Again, tcpdump can tell you what traffic is being blocked when you attempt to make the SSH connection for the authpf user.
Quote:
the pf command returns nothing, just immediately back to the command prompt
2. You have another configuration problem, if this is while the the user is authenticated and connected. If that's the case, no rules are anchored.
Quote:
tcpdump doesnt display anything related to the login. I do see blocks in athn0 on port 53

rule 0/(match) block in on athn0: 10.2.0.32.60596 > 4.4.4.4.53: 946+[|domain]
3. DNS is being blocked. DNS queries use UDP (and sometimes TCP) to destination port 53.
Reply With Quote
Old 7th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

When I edit /etc/authpf/authpf.rules do I have to run any commands to make it accept the changes? I was under the impression that authpf would read the file once someone logged in? So all i had to do was close putty and try again?

Right now I have everything open. SSH works the first try. Then on the second try and the telnet window closes immediately after typing the password. A reboot of the openbsd wireless server fixes this. What is going on?


Also I opened up 53 on tcp and tcpdump is not showing any telnet port blocking.
Reply With Quote
Old 7th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

It's late in my day and I am not about to manually review your rules. Instead, I'm going to assume that your issues are caused by operator error.

Load your base ruleset as you always would, with

# pfctl -f /path/to/file.

Test your rules and make sure they work. Any errors or faults must be corrected. You are not doing this.

You do not load the anchor rules with pfctl. These are loaded and unloaded at the anchor point in your base ruleset by the authpf shell. If you have been issuing pfctl commands in an attempt to manage authpf, stop. The only pfctl commands you will need other than the load command above are to inspect the loaded rules:

Base ruleset:

# pfctl -sr

Anchor ruleset. Empty when unloaded and inactive:

# pfctl -sr -a authpf/*

Last edited by jggimi; 7th July 2014 at 12:12 PM. Reason: clarity, typo - I should never reply to these threads with a phone.
Reply With Quote
Old 7th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

I have tested just about everything I know to do. I have highlighted the difference between a config that works and one that doesnt.

1 TCPdump does not display any output (other then the dns blocking)
2 It works fine as long as I do not filter any ports.


This configuration works
/etc/pf.conf
Code:
EXT_IF = "xl0"
WIRELESS_IF = "athn0"

auth_web = "10.1.0.1"

table <authpf_users> persist

block drop log all

match out on $EXT_IF from $WIRELESS_IF:network nat-to ($EXT_IF)

pass out quick on $EXT_IF inet proto { tcp, udp } from $WIRELESS_IF:network
pass in on $WIRELESS_IF inet proto tcp from any to 10.2.0.1 port ssh

anchor "authpf/*"

/etc/authpf/authpf.rules
Code:
WIRELESS_IF = "athn0"

pass in quick on $WIRELESS_IF proto tcp from $user_ip to any
pass in quick on $WIRELESS_IF proto udp from $user_ip to any
----------------------------------------------------------------------------------------------------

This configuration does not work
/etc/pf.conf
Code:
EXT_IF = "xl0"
WIRELESS_IF = "athn0"

auth_web = "10.1.0.1"

table <authpf_users> persist

block drop log all

match out on $EXT_IF from $WIRELESS_IF:network nat-to ($EXT_IF)

pass out quick on $EXT_IF inet proto { tcp, udp } from $WIRELESS_IF:network
pass in on $WIRELESS_IF inet proto tcp from any to 10.2.0.1 port ssh

anchor "authpf/*"

/etc/authpf/authpf.rules
Code:
WIRELESS_IF = "athn0"

TCP_PORTS = "{ 53 80 443 ssh }"
UDP_PORTS = "{ 53 }

pass in quick on $WIRELESS_IF proto tcp from $user_ip to any port $TCP_PORTS

pass in quick on $WIRELESS_IF proto udp from $user_ip to any port $UDP_PORTS



EDIT:

Also
Code:
pfctl -f /etc/pf.conf
gives me

Code:
Pfctl:warning: namespace collision with <authpf_users> global table.
Which I am not able to google any resolution on. Im about ready to format the box and start again.

Last edited by EverydayDiesel; 7th July 2014 at 09:36 PM.
Reply With Quote
Old 7th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

Here's a test configuration I would like you to try.

I assume your inner network is configured as 10.2.0.0/24, and the router's (gateway's) address on that network is 10.2.0.1. This means something akin to "inet 10.2.0.1/24" is in the hostname configuration file.

I assume your outer network is connected via the xl0 device.

I assume you have sshd(8) running on the inner router.

---

This test configuration uses a default pass ruleset, which is unusual. All block and pass rules use log so that you can see them match with # tcpdump -neti pflog0.

The base PF configuration has the following rules, from the general case through to the specific case. As a reminder, when quick is not used, the last matching rule wins. Note the NAT rule uses match.
Code:
# do not hang when blocking
set block-policy return

# the authpf users table is defined, but no rules will refer to it in this test
table <authpf_users> persist

# NAT traffic from the inner to outer network
match out on xl0 from 10.2.0.0/24 to any nat-to xl0

# allow all traffic by default
pass log all

# block the inner network
block in log from 10.2.0.0/24

# pass SSH inbound for authpf use:
pass in log proto tcp from 10.2.0.0/24 to 10.2.0.1 port ssh

# anchor point for authpf rules
anchor "authpf/*"
Please give this a try. I have not tested it, but this simple ruleset should allow all traffic except that originating from the inner network to pass freely. And on the inner network, the only thing allowed is SSH traffic to the router at 10.2.0.1. DNS is not allowed. ICMP is not allowed. The only network connection that should function is:

$ ssh [user@]10.2.0.1

If this ruleset works, please try the following configuration in /etc/authpf/authpf.rules
Code:
# allow this user to pass all traffic
pass from $user_ip to any
pass from any to $user_ip
If, after successfully authenticated, and while the authpf session remains active, the test device should be able to send and receive all traffic through this gateway.

While authenticated, there should be two rules in output to this command:

# pfctl -sr -a authpf/*

While authenticated, there should be the address of the authenticated devices output to this command:

# pfctl -t authpf_users -T show

While authenticated, there should be a process with username and IP address shown with this command:

$ ps -ax | grep authpf

Once the SSH session is disconnected, the rules should no longer appear, the table should be empty, and there will no longer be an authpf process.
Reply With Quote
Old 8th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

I believe you are seeing "namespace collision" messages because you created a table of the same name inside an anchor ruleset. I recall you had been trying to load authpf rules at anchor points with pfctl.

You are probably best off rebooting, to eliminate this kernel table, since you declared it persistent.
Reply With Quote
Old 9th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

Ok the ruleset you posted works but it fails once i start blocking ports.

Code:
# allow this user to pass all traffic
pass from $user_ip to any
pass from any to $user_ip

This code works
Code:
TCP_PORT = "{ 80 ssh }"
UDP_PORT = "{ 53 }"

pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT
pass out on athn0 proto udp from any to $user_ip port $UDP_PORT

pass from $user_ip to any
This code does NOT work
Code:
TCP_PORT = "{ 80 ssh }"
UDP_PORT = "{ 53 }"

pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT
pass out on athn0 proto udp from any to $user_ip port $UDP_PORT

pass in on athn0 proto tcp from $user_ip to any port $TCP_PORT
pass out on athn0 proto udp from $user_ip to any port $UDP_PORT

tcpdump shows nothing :-/
Code:
tcpdump -neti pflog0

Can you please show me the proper config for pf.conf and /etc/authpf/authpf.rules
Reply With Quote
Old 9th July 2014
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by EverydayDiesel View Post
Code:
TCP_PORT = "{ 80 ssh }"
UDP_PORT = "{ 53 }"
DNS communicates on port 53 using both TCP & UDP. You have specified use of only UDP.
Reply With Quote
Old 9th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default

Quote:
Originally Posted by EverydayDiesel View Post
Code:
# allow this user to pass all traffic
pass from $user_ip to any
pass from any to $user_ip
I neglected to add the log option to those two rules. My apologies.

While you are testing, you will find the log option very helpful. Some people use it only with their block rules, but when testing a new ruleset I prefer them on all rules.

A pass or block rule requires the log option for pflog(4) to capture its traffic.

I'm confused by the rule I highlighted below in red. It would only work if the innermost device is a webserver and an SSH server. I don't think that's what you intended, since your innermost device is intended to be a client.

Every TCP or UDP packet is defined by TWO different ports. An origination port, also called a source port, and a destination port. The $TCP_PORT numbers you defined are destination port numbers. Destination port numbers are listened to by servers, and sent to by clients typically using high numbered, random source ports.
Code:
TCP_PORT = "{ 80 ssh }"
UDP_PORT = "{ 53 }"

pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT
pass out on athn0 proto udp from any to $user_ip port $UDP_PORT

pass from $user_ip to any
If you want the authenticated device to be able to reach servers listening at the ports defined by $TCP_PORT, try this rule instead:

pass in proto tcp from $user_ip to any port $TCP_PORT

Check your pass rules -- most are written without consideration of destination port numbers associated with the server, not the client
Quote:
tcpdump shows nothing :-/
Make sure the log option is defined on every block rule - in that way you will be able to see the traffic that does not match any of your pass rules, and is caught by the block rules.

But, for better analysis of new rulesets, add the log option to your pass rules also. In that way, you can see which pass rule applies to passed traffic -- it may not be the rule you expect.

Last edited by jggimi; 9th July 2014 at 10:10 AM. Reason: clarity, typos, as usual. :(
Reply With Quote
Old 9th July 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,719
Thanked 214 Times in 189 Posts
Default Rule writing and analysis - jggimi's guide to figuring it out

General guidance from jggimi:
  1. Add the log option to all block rules during development and testing, so that pflog(4) can capture traffic that doesn't match any of your pass rules, and you can correct pass rules if necessary.
  2. Add the log option to all pass rules during development and testing, to ensure the traffic being passed is being passed by the intended pass rule, and not by an unintended rule.
  3. Document every rule, so that if you ask others for help, they will have a clear understanding of what you intended by the rule, and can more easily find errors for you.
  4. Document every rule, so that when you are diagnosing problems during development, you can more easily see rules that are in error yourself.
  5. Document every rule, because when you read your rules a month or a year or five years from now, you will understand what it is you intended.
  6. Document every rule, so that when the syntax changes in a future release, you will have an easier time making changes needed to upgrade.
  7. Remember that the incorrect use of in, out, from, to and on <interface> are the most common cause of errors. When a rule isn't matching its intended traffic, these directives are the usual suspects.
  8. Remember that source and destination port numbers are two very different things.
Additional recommendations:
  1. Avoid the use of on <interface> except where required, such as nat-to directives. Can from and to be used to define the rule?
  2. Avoid the use of in or out except where necessary. Can from and to be used to define the rule?
  3. Test and correct one rule at a time.

Last edited by jggimi; 9th July 2014 at 11:13 AM.
Reply With Quote
Old 15th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

jggimi and ocicat, I cant thank you enough for helping me get this going. I will tweak the rules one by one and see if I can get this right.

Also thank you for explaining the rules(destination/source ports), that is something that i havent had a really good understanding of.

(ps i am responding late because for some reason i didnt get the subscription email)
Reply With Quote
Old 16th July 2014
EverydayDiesel EverydayDiesel is offline
Shell Scout
 
Join Date: Jan 2009
Posts: 106
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by jggimi View Post
I'm confused by the rule I highlighted below in red. It would only work if the innermost device is a webserver and an SSH server. I don't think that's what you intended, since your innermost device is intended to be a client.

Every TCP or UDP packet is defined by TWO different ports. An origination port, also called a source port, and a destination port. The $TCP_PORT numbers you defined are destination port numbers. Destination port numbers are listened to by servers, and sent to by clients typically using high numbered, random source ports.
Code:
TCP_PORT = "{ 80 ssh }"
UDP_PORT = "{ 53 }"

pass in on athn0 proto tcp from any to $user_ip port $TCP_PORT
pass out on athn0 proto udp from any to $user_ip port $UDP_PORT

pass from $user_ip to any
If you want the authenticated device to be able to reach servers listening at the ports defined by $TCP_PORT, try this rule instead:

pass in proto tcp from $user_ip to any port $TCP_PORT

Check your pass rules -- most are written without consideration of destination port numbers associated with the server, not the client
Make sure the log option is defined on every block rule - in that way you will be able to see the traffic that does not match any of your pass rules, and is caught by the block rules.

But, for better analysis of new rulesets, add the log option to your pass rules also. In that way, you can see which pass rule applies to passed traffic -- it may not be the rule you expect.

I am running the SSH daemon and the HTTPD daemon on the same box (its a box that just does wireless connections)

is this still what i want?

pass in proto tcp from $user_ip to any port $TCP_PORT

--------------------------------------------------------------------

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


EDIT:

Quote:
Avoid the use of on <interface> except where required, such as nat-to directives. Can from and to be used to define the rule?
Avoid the use of in or out except where necessary. Can from and to be used to define the rule?
I usually use the interface and or in/out because of spoofing. Its something i learned when i first got into openbsd. Why do you say not to use them?

Last edited by EverydayDiesel; 16th July 2014 at 02:20 AM.
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 01:59 AM.


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