support output of firewall rules

[himrock922]

Hi all.

A firewall rules add or delete via libioc, that result wants output. To implement it, I did commit of Firewall.rules method. It is very simply, Because, I want review(Also, it's need or unnecessary) Regards,

Make sure to follow and check these boxes before submitting a PR! Thank you.

• [x] Explain the feature
• [x] Read CONTRIBUTING.md

[gronke]

@himrock922 in case you want to get a list of all firewall rules active, another way to get them is to filter the list of all jails for running jails that use Secure VNET. (There are no user managed firewall rules possible yet, so ipfw is only used when Secure VNET (e.g. vnet0::bridge0) is enabled.

At the moment, this appears to be the quickest way to get all running jails with Secure VNET enabled.

[j for j in libioc.Jails("running=True") if any([n._is_secure_vnet_bridge for n in j.networks])]

Unfortunately the Firewall class is a minimal write-only abstraction of IPFW. This PR brings us a large step forward. 👍

[himrock922]

@gronke

 Getting a generic list of ipfw rules on a host, seems to be a bit out of scope for libioc, but I am convinced that the ability to verify if the expected rules are set, can be helpful.

---
Unfortunately the Firewall class is a minimal write-only abstraction of IPFW. This PR brings us a large step forward.

Thanks, I thinks so it too. Rather, you might as well detach firewall function from libioc? It is firewall operations only python library.

[gronke]

Rather, you might as well detach firewall function from libioc?

That's a great idea! I'll investigate our options and invite you to a repository.

[himrock922]

That's a great idea! I'll investigate our options and invite you to a repository.

@gronke Thanks! I'm waiting for your response.

[gronke]

That's a great idea! I'll investigate our options and invite you to a repository.

@gronke Thanks! I'm waiting for your response.

Unfortunately there is no libc interface for ipfw. I've looked into the sbin/ipfw implementation of FreeBSD but did not come up with a proper idea to implement this in native Python 3: https://github.com/freebsd/freebsd/blob/50b3d8bf81088f77cb3a48d9d9f7f368ecfb42b5/sbin/ipfw/ipfw2.c#L2685-L2742

As so often, @fabianfreyer could have the idea 😍

I would not like to implement a wrapper that parses sbin/ipfw stdout, because everyone could already do that on their own today. Why making it more complex then? But with programmatic access to IPFW rules, having a library would make so much sense.

[himrock922]

Hi @gronke

Unfortunately there is no libc interface for ipfw. I've looked into the sbin/ipfw implementation of FreeBSD but did not come up with a proper idea to implement this in native Python 3: https://github.com/freebsd/freebsd/blob/50b3d8bf81088f77cb3a48d9d9f7f368ecfb42b5/sbin/ipfw/ipfw2.c#L2685-L2742

Thank you for researching and I'm sorry...

I would not like to implement a wrapper that parses sbin/ipfw stdout, because everyone could already do that on their own today. Why making it more complex then?

Right. I'm think it too.

But, If container management tools development, I'm think that need firewall function(or NAT) flatly handling too. (Let's put aside it, the libioc include or exclude that support firewall function.)

But with programmatic access to IPFW rules, having a library would make so much sense.

Right. I'm think it too. this reason is same above.

Once, I'd develop it, the library for firewall function handling.

[fabianfreyer]

One question that comes to my mind is: why ipfw specifically over the other options for firewalling? Why not, e.g. pf(4)? Afaik, [npf(7)] is being ported to FreeBSD by @gvnn3, and has libnpf(3). ipf(4) also has a programmatic interface. The ipfw programmatic interface seems to be undocumented at this point, so I'm not sure how stable it would be to write bindings for it directly.

For an example of a pf(4) consumer, take a look at filter.c in ftp-proxy(8).

Finally, you could also use divert(4) to write your own filter (though ~I'm pretty sure that's not a good idea~ this may be a good idea with npf(7)).

That being said,

Rather, you might as well detach firewall function from libioc?

If there were a programmatic interface with several different firewall backends

[himrock922]

Hi, @fabianfreyer

One question that comes to my mind is: why ipfw specifically over the other options for firewalling? Why not, e.g. pf(4)? Afaik, npf(7) is being ported to FreeBSD too, and has libnpf(3). ipf(4) also has a programmatic interface. The ipfw programmatic interface seems to be undocumented at this point, so I'm not sure how stable it would be to write bindings for it directly.

Honestly, Because the libioc uses ipfw, I did only used ipfw too.

For an example of a pf(4) consumer, take a look at filter.c in ftp-proxy(8).

Thanks! I'm read it.

Finally, you could also use divert(4) to write your own filter (though ~I'm pretty sure that's not a good idea~ this may be a good idea with npf(7)).

Yes, Actually, I'm setting for firewall via ipfw and divert. But, I'm want setting it via web application. Actually I'm development it.

https://github.com/himrock922/jaisting

If there were a programmatic interface with several different firewall backends

This is misunderstanding. I want said, it's only create another repository from Firewall.py.

[fabianfreyer]

This is misunderstanding.

ah, no, I was just dreaming ;)

[gronke]

One question that comes to my mind is: why ipfw specifically over the other options for firewalling?

Because we need layer 2 filtering on bridges to mitigate ARP Spoofing from jails that use the Secure VNET feature (host bridge <> epair <> filter bridge <> epair <> jail).

[himrock922]

Hi @gronke

One question that comes to my mind is: why ipfw specifically over the other options for firewalling?

Because we need layer 2 filtering on bridges to mitigate ARP Spoofing from jails that use the Secure VNET feature (host bridge <> epair <> filter bridge <> epair <> jail).

Is this answer that ipfw is better compared to other firewall management tools?

Can't blocking ARP spoofing with other tools anywhere..?

[fabianfreyer]

@himrock922 it means that ipfw is an OSI layer 2 firewall, while the others are OSI layer 3. Libioc puts jails on the same layer2 domain, therefore uses ipfw. If it would not do that (but instead e.g. route and/or redirect), a layer 3 firewall would be fine as well.

So no, in general it is not "better", just a better tool for this specific job given the constraints.

[gronke]

Manipulation of existing host network devices is not performed by libioc. A VNET jail can be connected to a bridge, but we do not setup virtual routing for it (yet).

The network configuration was pretty much inherited from iocage. For advanced network configuration, such as NAT or local routing (instead of bridging), I'd like to overthink this concept and watch out for suitable standards, such as opencontainers.

[himrock922]

The network configuration was pretty much inherited from iocage. For advanced network configuration, such as NAT or local routing (instead of bridging), I'd like to overthink this concept and watch out for suitable standards, such as opencontainers.

Right.To configuration advanced network for container management, I agree for wait there will establish standards or draft.

Temporary, I'll process development to establish my container hosting system.

[himrock922]

Hi @gronke. https://github.com/himrock922/py-ipfw

I had develop IPFW wrapper for Python. I had only implement ipfw -a list. Therefore, the libioc doesn't need for firewall results. I do continue that development of IPFW wrapper.

You can close this PR. Thanks.

[gronke]

Sounds great, @himrock922.

In the near future I'll look into routing (instead of layer2 filtering) as solution to move firewall tasks to PF. That's probably the right time to make sure firewall rules are configured through such a wrapper.

[himrock922]

Hi All. https://github.com/himrock922/py-ipfw

py-ipfw has supported function add and delete for ipfw by this development. Therefore, this PR close.

Thanks.

[igalic]

starts watching

[gronke]

starts watching

same here :) I'd be happy to replace the IPFW wrapper with a real library that does proper parsing of firewall rules. I would be even more happy to replace IPFW layer 2 filtering with PF, but that's a totally different task.