Open debdrup opened 5 years ago
Thanks for show interest on this. However what you ask, It's not easy. the first thing I'd like to work is to rework the pf support using anchor. I can rework this part of the code to be "firewall independent". In this way, it should be easier to add support to other firewalls.
Ah, I see - well, it doesn't have to be right now, and it's better to get it done properly when you're going to be doing it - so as long as it gets done, it doesn't have to be soon. I think it would also give pot an advantage over many of the other similar tools, so there's something to consider. :)
IPFW tables could really simplify things because they're key-value maps instead of just sets and the mapped value(s) can be used as part of the argument to ipfw actions e.g. forward to this address and port. I' m willing to look into this. I suspect that everything pot needs can be expressed in IPFW with a short fixed set of rules.
I look into what firewall features pot uses so far and found this:
Since pot already makes use of FreeBSD specific features here is how I would like to improve this:
rcorder
.rcorder
until either a hook returns success or failure or all hooks have executed.$POT_
.This could at the very least extend the existing hooks for:
Additional hooks could be added to handle network interfaces (physical interface for alias and inherit, bridge+epair for vnet):
Pot should include at least one default implementation for each type of hook to work out of the box and serve as example.
@pizzamig : How do you think about this design proposal?
An other question is how these hooks should be stored. Right now pot export doesn't preserve the hooks on the exported jail. This is a problem because for some setups these hooks are required e.g. to add jails to PF tables.
first the easy question: hooks are copied in the conf
folder of the pot.
To make them part of an exported jail, you have to take the snapshot AFTER the set-hook.
pot export
generates the image from the last available snapshot, not the current status.
Design proposal: honestly it seems very complicated to me and it needs a major rework.
My original idea about firewall was this: define a set of functions to use the firewall, kind of an API.
Then, provide an implementation for pf
and another one for ipfw
and let the user choose.
In general, I stand to support only 1 hook, it's a good way to extend pot
and try new features, that at the end should be integrated in the framework.
Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...
first the easy question: hooks are copied in the
conf
folder of the pot. To make them part of an exported jail, you have to take the snapshot AFTER the set-hook.pot export
generates the image from the last available snapshot, not the current status.Design proposal: honestly it seems very complicated to me and it needs a major rework.
My original idea about firewall was this: define a set of functions to use the firewall, kind of an API. Then, provide an implementation for
pf
and another one foripfw
and let the user choose.In general, I stand to support only 1 hook, it's a good way to extend
pot
and try new features, that at the end should be integrated in the framework.Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...
@pizzamig @Crest I feel like this is the kind of improvement that should come as a pull request from someone who is using pot in production and requiring that feature.
I asked because I have a use-case that isn't covered by the existing features e.g. UDP based services and automatic IPv6 aliases. Scripting around those limitations with the existing hooks and ansible is possible, but time consuming and fragile.
I just revisited the design and there is no reason to embed support for multiple hooks on a single jail/interface into pot. Should the user want this a hook can be used to loop over the other hooks with whatever merge and shortcut behaviour fits his usecase.
The one thing missing from pot, I think, is making pot either capable of using either or both IPFW and IPF, since both have people who actively use and maintain them.
Another option which is arguably better but may involve more work (and changing ABI/KBI and would thus probably involve a major version bump?) would be to adopt a principle similar to that of blacklistd. It uses a firewall-agnostic API where the sysadmin supplies the commands necessary for certain functions, and then that command is simply executed. This would have the added benefit that if, say, npf (NetBSD Packet Filter by rmind@netbsd) was ever ported to FreeBSD, or another 4th firewall was added, it would be trivial to add support for these.