Helper tables or macros

[mikemol]

It would be very nice to have helper tables to jump to, or, at the very least, macros for inserting recurring sets of rules.

For example, I have five interfaces on one machine which have several rules in common:

• All accept ping
• All accept ssh
• All accept smtp

Two of the interfaces also have these commonalities:

• Accepts DHCP
• Accepts dns
• Accepts ntp
• Accepts smtp
• Accepts IPP
• Accepts connections to a proxy server

Additional groupable rules would include internally-facing ICMPv6 vs externally-facing ICMPv6 behaviors.

[philwhineray]

As bash is the base for firehol you should be already able to do this, e.g.:

standard() {
server ping accept
server ssh accept
}

interface "$wan" wan
policy deny
standard

interface "$lan" lan
policy deny
standard

Works just fine. Perhaps we could add an example showing this usage?

I notice that adding a parameter will defeat ipv4/ipv6 autodetection so the the following will not work without making the wan interface "standard" command ipv4 explicitly:

standard() {
server ping accept "$@"
server ssh accept "$@"
}

interface "$wan" wan
policy deny
standard src 10.0.0.0/8

interface "$lan" lan
policy deny
standard

[mikemol]

philwhineray wrote:

Leaving aside whether the use of bash is ideal as a base for firehol, you should be already able to do this, e.g.:

standard() {
server ping accept
server ssh accept
}

interface "$wan" wan
policy deny
standard

interface "$lan" lan
policy deny
standard

Works just fine. Perhaps we could add an example showing this usage?

I notice that adding a parameter will defeat ipv4/ipv6 autodetection so the the following will not work without making the wan interface "standard" command ipv4 explicitly:

standard() {
server ping accept "$@"
server ssh accept "$@"
}

interface "$wan" wan
policy deny
standard src 10.0.0.0/8

interface "$lan" lan
policy deny
standard src

Interesting. My approach for that would have been:

standard() {
server ping accept
server ssh accept
}

interface "spc$wan" wan src 10.0.0.0/8
policy deny
standard

interface "$wan" wan
policy deny

interface "$lan" lan
policy deny
standard

I suppose I should look into how the ipv4/ipv6 autodetection works.

[philwhineray]

interface "spc$wan" wan src 10.0.0.0/8

Nice; I had not considered that way of doing it. Makes a lot of sense if there will be groups of IPs and services. I currently just have bash variables everywhere.

Mostly I just wanted to check that it was possible to pass parameters through to functions and just stumbled on the problem with the autodetection.

[mikemol]

philwhineray wrote:

interface "spc$wan" wan src 10.0.0.0/8

Nice; I had not considered that way of doing it. Makes a lot of sense if there will be groups of IPs and services. I currently just have bash variables everywhere.

Mostly I just wanted to check that it was possible to pass parameters through to functions and just stumbled on the problem with the autodetection.

I have it this way mostly because my firehol config is a derivative of
running "firehol helpme" a long time ago. Your approach is about equally
alien to me. :)

[philwhineray]

Quick question; do we agree that bash functions are sufficient to meet your original requirement or are you thinking of something more?

[mikemol]

The "something more" I'd like to see eventually is being able to avoid
reinstanciating the same table multiple times, which causes a large
increase in the number of rules. With iptables, if I have a table, I
could jump to that table from wherever. When I leave that table, it
returns flow back to wherever the jump came from.

I'm uncertain, though if that's just an aesthetic difference, or if
there are notable performance gains to be found. (Either in time
required to generate the firewall rules or in iptables overhead once
the firewall is set up)

:wq

[philwhineray]

Okay, I follow now. I guess something should be possible with a bit of
thought.
On Jan 28, 2012 3:49 PM, "Michael Mol" <
reply@reply.github.com>
wrote:

The "something more" I'd like to see eventually is being able to avoid
reinstanciating the same table multiple times, which causes a large
increase in the number of rules. With iptables, if I have a table, I
could jump to that table from wherever. When I leave that table, it
returns flow back to wherever the jump came from.

I'm uncertain, though if that's just an aesthetic difference, or if
there are notable performance gains to be found. (Either in time
required to generate the firewall rules or in iptables overhead once
the firewall is set up)

:wq

---

Reply to this email directly or view it on GitHub:
#6 (comment)