I'd like to get some feedback on the feasibility of some new features for pf and the feasibility of them being implemented by the current pf hackers.
For large table support, what do people think of the idea of "read only" external tables. For instance, using CDB [http://www.corpit.ru/mjt/tinycdb.html is a pd implementation of djb's cdb (since the license for the original wouldn't be acceptable)] or perhaps Judy arrays http://judy.sourceforge.net/ [but this is LGPL] ? It seems that the memory limitations related to the current table implementation are due to the fact that all the records are stored in memory and statistics are maintained for each entry. Similar stats (except for aging) can be had by using a separate rule for each table and using the per rule stats: table <sshbrutefrc> persist file "/etc/ssh_brutes.txt" {} table <bogons> persist file "/etc/bogons-cidr-all.txt" {} table <spammers> persist file "/etc/spammers.txt" {} block drop quick log on $ext_if from {<sshbrutefrc>} block drop quick log on $ext_if proto icmp from {<spammers>} block drop quick log on $ext_if proto udp from {<spammers>} block drop quick log on $ext_if proto tcp from {<spammers>} to port != 25 block drop quick log on $ext_if from {<bogons>} @0 block drop log quick on dc0 from <sshbrutefrc:67> to any [ Evaluations: 1415858 Packets: 414 Bytes: 24376 States: 0 ] @1 block drop log quick on dc0 proto icmp from <spammers:79461> to any [ Evaluations: 315126 Packets: 0 Bytes: 0 States: 0 ] @2 block drop log quick on dc0 proto udp from <spammers:79461> to any [ Evaluations: 302219 Packets: 12 Bytes: 936 States: 0 ] @3 block drop log quick on dc0 proto tcp from <spammers:79461> to any port != smtp [ Evaluations: 13587 Packets: 362 Bytes: 18469 States: 0 ] @4 block drop log quick on dc0 from <bogons:7064> to any [ Evaluations: 314752 Packets: 0 Bytes: 0 States: 0 ] By eliminating the need to maintain age/stats on individual entries, the read only table feature can use efficient in memory structures, files, databases, etc for a simple lookup but not use the memory required for tracking active table entries. Something like: table <sshbrutefrc> ro cdb "/etc/sshbrutefrc.cdb" Obviously, then all aging and maintenance of the table would fall to external programs. The second more outlandish feature I call "The Decider" which would be similar to read only tables but would communicate with an external program which could use more complex criteria to decide if that packet was part of the dynamic table or not. Basically, a process driven dynamic table lookup: decider <tdcd1> 127.0.0.1:2727 400ms:no block drop quick log on $ext_if from {<tdcd1:spammer_chk>} pf would pass the packet details and the parameter after the decider_name: and would get a yes/no response, maybe an optional timeout is included in the decider declaration and if it is exceeded it defaults to whatever is specified. Of course, this would be painfully slow and when misused would cause people to bitch about pf being slow. Thanks for any ideas/feedback.
