DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Security

FreeBSD Security Securing FreeBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd November 2015
jasonvp's Avatar
jasonvp jasonvp is offline
Real Name: Jason
Port Guard
 
Join Date: Nov 2015
Location: Northern VA
Posts: 15
Default PF: Help With Tables vs Macros

Hey gang -

I posted this over on the FreeBSD.org forums, and figured I'd post it here, too. I just built a new server running FreeBSD 10.2 and locked it down with pf. After spinning up a bunch of jails (sendmail over here, named over there, a few web servers here and there, etc) I punched holes in the pf.conf to allow traffic to and from them. I did so using macros in the /etc/pf.conf file.

All good.

A few of the macros allow a range of loopbacks to talk to one another so that the jails can actually communicate internally with themselves. Meaning: jail1 can talk to jail1 via its loopback. Jail2 can talk to jail2 via it's loopback, etc.

Code:
# IPv4 and v6 loopbacks
ipv4_loopback = "{ 127.0.0.0/8 }"
ipv6_loopback = "{ ::/64 }"
.
.
.
pass in quick from $ipv4_loopback to $ipv4_loopback
pass in quick from $ipv6_loopback to $ipv6_loopback
And as a test, I have a sendmail milter installed on one of my jails that its sendmail talks to via 127.0.0.1. That works.

I tried to get tricky and convert the macros over to tables, like so:
Code:
# IPv4 and v6 loopbacks
table <ipv4_loopback> const {127.0.0.0/8}
table <ipv6_loopback> const {::/64}
.
.
.
# Local loop to loop allows
pass in quick from <ipv4_loopback> to <ipv4_loopback>
pass in quick from <ipv6_loopback> to <ipv6_loopback>
Once I did that and loaded the new rules, sendmail on that aforementioned jail could no longer talk to its local (127.0.0.1) milter. I even tried to telnet to the milter's port on the jail and no luck. Reverting the pf rules back to macros worked.

So: I clearly don't understand the use of tables vs macros. Any guidance? Calling me an idiot is perfectly acceptable here if I'm doing something drastically stupid.

Thanks!
Reply With Quote
  #2   (View Single Post)  
Old 23rd November 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,519
Default

Hello, and welcome!

The fragment of pf.conf shared here doesn't indicate any obvious problem source. So I'll reply only generally. If the traffic is being blocked, it's probably either not matching the rule, or .... never reached the rule having matched a prior quick rule.

PF diagnostics is actually pretty easy. Add the log option to all your pass and block rules, then use tcpdump(8) with your pflog(4) device. You'll be able to see what rule is passing/blocking the traffic of interest.

(For those who use more modern PF variants, adding logging to all pass/block rules can be done with a single match rule.)

Last edited by jggimi; 23rd November 2015 at 03:32 PM. Reason: typo
Reply With Quote
  #3   (View Single Post)  
Old 23rd November 2015
jasonvp's Avatar
jasonvp jasonvp is offline
Real Name: Jason
Port Guard
 
Join Date: Nov 2015
Location: Northern VA
Posts: 15
Default

Quote:
Originally Posted by jggimi View Post
Hello, and welcome!
Thank you.

Quote:
The fragment of pf.conf shared here doesn't indicate any obvious problem source. .
Hm. Well the only block I have is at the very end of the pf ruleset. I'm a "explicitly allow, assume denied" kind of firewall guy. When I made the change, I did a:
Code:
# service pf reload
I'm wondering if, perhaps, the change was so large that I should have just restarted pf?

I'll try the logging as you suggested. Thanks for that.
Reply With Quote
  #4   (View Single Post)  
Old 23rd November 2015
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,519
Default

If you only have one block, then the pass rule with tables is not matching. I can't tell why with the information presented here. You may be able to when you watch tcpdump traffic. It's possible your tables do not contain what you intended (you're using the const option), so inspecting table contents with pfctl(8) may be of use also.

I don't know if restarting would make a difference or not. I tend to doubt it, but then I'm not 100% sure. That's because PF on FreeBSD is a fork based on a version of PF in OpenBSD as it existed in 2007, and there has been divergence between the two PFs ever since.
Reply With Quote
  #5   (View Single Post)  
Old 23rd November 2015
jasonvp's Avatar
jasonvp jasonvp is offline
Real Name: Jason
Port Guard
 
Join Date: Nov 2015
Location: Northern VA
Posts: 15
Default

Quote:
Originally Posted by jggimi View Post
If you only have one block, then the pass rule with tables is not matching...
I figured it out using the log, so thank you for that. It turns out the connection wasn't sourcing nor terminating on the jail's loopback (127.0.0.1) IP address. It was sourcing and terminating on the jail's public IP, even though sendmail's config tells it to use the loopback.

So I added a pf line on the host:
Quote:
pass in quick proto tcp from <riddler> to <riddler>
(riddler is the jail in question, defined further up in the file)

and voila: it works. The very strange this is: I'm not exactly sure how it was working prior to the tables because the macro version should have dropped it as well.

I'm going to chalk this up to me being ignorant. Thanks for the suggestions and guidance!
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
pf.conf place multiple tables in one variable daemonbak OpenBSD Security 1 21st July 2015 10:12 AM
VPN Client (tun) and routing tables irukandji General software and network 2 30th September 2014 05:29 AM
OpenBSD 5.0 and Current i386 buggy acpi tables shep OpenBSD Installation and Upgrading 6 14th July 2014 09:16 PM
pf tables how long values stored ijk FreeBSD Security 3 12th August 2008 11:45 AM
PF <tables> hunteronline FreeBSD Security 8 16th July 2008 08:52 PM


All times are GMT. The time now is 05:17 AM.


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