PDA

View Full Version : PF <tables>


hunteronline
07-15-2008, 08:31 PM
I use a very basic pf.conf on a web server to drop known problem IPs

pf.conf:

# Tables: similar to macros, but more flexible for many addresses.
table <rfc1918> const { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
table <garbage> persist file "/etc/pf.garbage.txt"
table <whitelist> persist file "/etc/pf.whitelist.txt"
table <ssh-violations> persist file "/etc/ssh-violations.txt"


block in all
block drop in quick from <rfc1918> to any
block drop in quick from <garbage> to any
block drop in quick from <ssh-violations> to any
pass in all

The <garbage> table had thousands of IPs in it before the rule "block drop in quick from <garbage> to any" was commented out while tracking down a problem. Pf.conf was tested and reloaded using:

pfctl -vvv -f /etc/pf.conf ; sleep 90 ; pfctl -vvv -f /etc/pf.conf.open

pfctl -vvv -f /etc/pf.conf

The problem had nothing to do with any IP in the <garbage> table and the rule was rule was re-enabled. Now when I use "pfctl -t garbage -T show" the table is empty.

pfctl -sa -r -vvv | less - loaded rules with line numbers

Is this normal or am I missing something ?

Thanks

chris
07-15-2008, 10:48 PM
Does the file /etc/pf.garbage.txt actually have anything inside it?
What about the rest of your tables, did they loose any info as well -- what's the output of
# pfctl -vvsTables

I've just tested flushing all possible parameters including tables by the following command
# pfctl -Fa -f /etc/pf.conf
but my /etc/blacklist file which is implemented exactly the same as your /etc/pf.garbage.txt file remained untouched so if your file is empty I'd have thought it was not done by PF.

hunteronline
07-16-2008, 12:25 AM
Thanks for the reply Chris;

I can duplicate what happened and I find it odd to say the least. This is what I did to replicate the table emptying for some reason unknown to me:

Added an IP range to <ssh-violations>:

pfctl -t ssh-violations -T add 62.141.48.0/20

Ran:

pfctl -t ssh-violations -T show --- IP range is there

- Commented out <ssh-violations> rule eg:
# Tables: similar to macros, but more flexible for many addresses.
table <rfc1918> const { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
table <garbage> persist file "/etc/pf.garbage.txt"
table <whitelist> persist file "/etc/pf.whitelist.txt"
table <ssh-violations> persist file "/etc/ssh-violations.txt"


block in all
block drop in quick from <rfc1918> to any
block drop in quick from <garbage> to any
#block drop in quick from <ssh-violations> to any
pass in all

Tested:

pfctl -vvv -f /etc/pf.conf ; sleep 90 ; pfctl -vvv -f /etc/pf.conf.open

Loaded:

pfctl -vvv -f /etc/pf.conf

Ran:
pfctl -t ssh-violations -T show --- table is empty!!!!

Uncomment <ssh-violations>:

block in all
block drop in quick from <rfc1918> to any
block drop in quick from <garbage> to any
block drop in quick from <ssh-violations> to any
pass in all

Ran, test, loaded and "pfctl -t ssh-violations -T show", table is empty.

Nonesuch
07-16-2008, 01:23 AM
As chris asked, do you have anything in the file /etc/pf.garbage.txt?

Perhaps you are misunderstanding how "persist" works, and how "file" works?

The "persist" adjective is not about classic object persistence, all it does is ensure that even if no current rules are using a table, that table still gets allocated. It's mostly useful when you are dynamically adding rules with anchors and know you will refer to a table in a future dynamic rule, even though no current rule uses that table.


PF will never writeto the file, it only reads from the file, and that only once at the time the rules are loaded/reloaded.

If you want to save the table contents to a file and have them survive across rule reloading and across reboots, you need a separate userland script to handle this activity.

hunteronline
07-16-2008, 01:45 AM
" ... do you have anything in the file /etc/pf.garbage.txt?" Yes , IP ranges I have reentered after I found the table to be empty. At one time there was over a thousand IP ranges n the garbage table.

I did think table contents would "survive across rule reloading and across reboots" and that is why I asked, "Is this normal or am I missing something ?"

chris
07-16-2008, 05:14 PM
Forgive me for sounding boring but I just want to make sure we're both understanding each other, what is the output of;
cat /etc/pf.garbage.txt
I want to make sure that you know there is a difference between adding IPs to the table via PF and adding manually IPs to the table using a file editor such as vi/pico/nano. IPs added to the table via PF will NOT remain there after you have reloaded the config file but if you manually add an IP to the file it will never be removed from the file unless you remove it yourself.

So, for example, rather than;
pfctl -t ssh-violations -T add 62.141.48.0/20
instead go for;
echo '62.141.48.0/20' >> /etc/ssh-violations.txt

That way your IP ranges will never get removed.

hunteronline
07-16-2008, 09:03 PM
Thanks Chris, I had the wrong perception of exactly what "persist" ment. I had been using the "pfctl" method of adding IPs to tables and was surprised when I found tables empty after my "test and reload".

I went back to the manpages and found:

A table can also be initialized with an address list specified in
one or more external files, using the following syntax:

table <spam> persist file "/etc/spammers" file "/etc/openrelays"

If I use an external file I need to reload the pf.conf. If I use "echo '62.141.48.0/20' >> /etc/ssh-violations.txt" do I need to reload pf.conf ?(eg- pfctl -vvv -f /etc/pf.conf)

chris
07-16-2008, 09:16 PM
Yes, you will need to reload PF once you've manually added an IP to a table using echo or something similar. Unless you really need extreme verbose output then just pfctl -f /etc/pf.conf will do as a reload command.

hunteronline
07-16-2008, 09:52 PM
Thanks Chris, I'm now desiding which method to use even though I don't really see any difference.

I case your are curious where I get the IP ranges to add to the tables. They come from the Mod_Security log file (modsec_audit.log). Dropping known garbage is a proactive approach and over time it has paid off.