DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 25th June 2021
philomathic_life philomathic_life is offline
Real Name: Zack
Port Guard
 
Join Date: Feb 2021
Location: Littleton, CO USA
Posts: 12
Default Questions about static-port and how pf keeps state.

Question 1. According to pf.conf(5), the static-port option with nat-to rules "prevents pf(4) from modifying the source port on TCP and UDP packets." The way that I interpret that is if I have an IPv4 address, i, that gets NATed to the IPv4 address, j, the source port that was used by i will not be translated to another port on j. A brief test seems to support this interpretation as beta$ pfctl -s state | grep "192.168.2.2" outputted content that showed the source port that was used was not being changed. If this is true though, then it would only take 302 different local devices/IPv4 addresses connecting to the same destination IPv4 address + port (using the same protocol (e.g., TCP)) before the probability of a "port collision" exceeds 50%. I'm guessing that pf(4) simply attempts to not translate the source port; however in the event that that source port is already being used by another IPv4 address connecting to the same destination IPv4 address + port, then it will translate the source port to a port that is unused. Furthermore, subsequent connections with the same IPv4 address and port will get translated to the same port. Is this correct?

Question 2. I know that pf(4) by default keeps state of connections thus freeing one from having to create explicit rules that allow returned traffic. I would like to test my comprehension of the following situations:

a. beta$ cat /etc/pf.conf

HTML Code:
match out on em0 inet from alc0:network to any nat-to (em0)
pass in quick on alc0 inet
pass out quick on em0 inet
block quick all
b. beta$ cat /etc/pf.conf

HTML Code:
match out on em0 inet from alc0:network to any nat-to (em0)
pass in quick on alc0 inet proto { udp tcp } to any port 80
pass out quick on em0 inet proto { udp tcp } to any port 80
block quick all
Am I correct that both a. and b. will cause pf(4) to block returning traffic if either the IPv4 address or port (regardless if it's TCP or UDP) is different than what the destination IP or port were when the traffic was initially sent—in this case let's assume initial connections were made to the destination port 80?

The reason I ask is that according to this post on CALOMEL, "Sending three UDP packets to three different machines (all on the same port) creates three entries on a symmetric NAT and only one on a cone NAT. These two extra entries are what breaks Xbox Live. When you talk to the Live servers they remember the port you connected on and tell other Xboxes to talk to you over that same port. If your NAT is symmetric (default for pf) then it blocks the traffic from the other Xboxes as only the Live server is allowed back on that port. We need to use the 'static-port' nat directive and allow traffic using our anchor."

This makes it seem that if at least UDP is being used the response traffic is allowed to be from a different IP than the destination IP that was used in the initial connection. The reason I have both a. and b. is that while I realize b. will only allow initial traffic to port 80 and a. allows all traffic, I don't know if explicitly stating a port is necessary to ensure that the returned traffic is from the same port.

Please correct any mistakes in my comprehension or confirm my interpretations.

Last edited by philomathic_life; 26th June 2021 at 12:33 AM.
Reply With Quote
  #2   (View Single Post)  
Old 26th June 2021
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Re: static-port: There's a lot that goes into the structure of a state table entry, far more than just address and port numbers. See /sys/net/pfvar.h for these details. It is my untested belief that you won't see NAT collision issues if you need to set a static-port rule for an application. There's no discussion of it that I can find in the misc@ mailing list archives.

Re: Your question about pass rules under NAT. This kind of esoteric question is best tested with traffic to ensure you're passing what you intend, and blocking what you intend. Using the log option on both your pass and block rules will allow you to track pflog(4) actions with tcpdump(8).

Two additional thoughts: 1) I generally try to avoid using a quick rule unless it is absolutely necessary. Any matching quick rule will be applied and all subsequent rules will be ignored. This is rarely what I want or need. I try to start with general rules, then the following rules close in to more specific requirements. 2) I have never trusted that third party site you reference -- while I don't know the entry you cited specifically, the site has been a constant source of misinformation about the OS for many years, according to every developer who has ever responded about its information quality publicly on misc@, ports@, or tech@ during my nearly 20 year history as an OpenBSD user.
Reply With Quote
  #3   (View Single Post)  
Old 27th June 2021
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

As mentioned by jggimi, you can answer most of your questions by enabling logging in your pf rule.

To show how you could set up the logging, I will use the first rule set that you posted (adjusted to my system):.

Code:
# cat philo-log.pf                                                                         

#match out on em0 inet from alc0:network to any nat-to (em0)
match out log (all,to pflog0) on egress inet from wlan:network to any nat-to (egress)

#pass in quick on alc0 inet
pass in quick log (all, to pflog1) on wlan inet

#pass out quick on em0 inet
pass out quick log (all, to pflog2) on egress inet
block quick log (all,to pflog3) all

# ifconfig pflog1 up         
# ifconfig pflog2 up 
# ifconfig pflog3 up 

#pfctl -vvf philo-log.pf   
Loaded 714 passive OS fingerprints
@0 match out log (all) on egress inet from 192.168.0.0/24 to any nat-to (egress:*) round-robin
@1 pass in log (all, to pflog1) quick on wlan inet all flags S/SA
@2 pass out log (all, to pflog2) quick on egress inet all flags S/SA
@3 block drop log (all, to pflog3) quick all

# pfctl -vvsr
@0 match out log (all) on egress inet from 192.168.0.0/24 to any nat-to (egress:3) round-robin
  [ Evaluations: 18        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 6872 State Creations: 0     ]
@1 pass in log (all, to pflog1) quick on wlan inet all flags S/SA
  [ Evaluations: 18        Packets: 11        Bytes: 308         States: 1     ]
  [ Inserted: uid 0 pid 6872 State Creations: 6     ]
@2 pass out log (all, to pflog2) quick on egress inet all flags S/SA
  [ Evaluations: 12        Packets: 24        Bytes: 2056        States: 0     ]
  [ Inserted: uid 0 pid 6872 State Creations: 12    ]
@3 block drop log (all, to pflog3) quick all
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 6872 State Creations: 0     ]

# tcpdump -eni pflog2
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog2, link-type PFLOG
05:18:38.317708 rule 2/(match) pass out on bge0: 192.168.222.242.17496 >
 213.154.236.182.123: v4 client strat 0 poll 0 prec 0 [tos 0x10]
05:18:38.326393 rule 2/(match) pass in on bge0: 213.154.236.182.123 >
192.168.222.242.17496: v4 server strat 2 poll 3 prec -24 (DF) [tos 0xb8]
You can see that the log (all, to pflog2) shows the reply. A simple log will only show the initial packet that creates 'state'.

Let us know what you find out
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Reply

Tags
nat, pf

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
Round-Robin AND Static-Port in the same rule? daemonbak OpenBSD Security 1 17th July 2015 01:58 PM
The current state of NetBSD Oko NetBSD General 87 16th May 2015 04:08 PM
FreeBSD The state of 802.11n on FreeBSD joekiser News 0 27th December 2011 08:15 PM
current state of virtualization? MBybee OpenBSD Packages and Ports 4 14th April 2011 07:27 PM
pftop state query. bsdnewbie999 OpenBSD General 1 10th April 2009 03:33 AM


All times are GMT. The time now is 03:17 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