arno-iptables-firewall / aif

GNU General Public License v2.0
151 stars 24 forks source link

lan-inet nolog settings #16

Open arnova opened 9 years ago

arnova commented 9 years ago

lan-inet rules should have nolog settings for reject/deny

abelbeck commented 9 years ago

Hi Arno,

Can you be more specific...

We have global logging variables as follows:

LAN_INET_HOST_DENY_xxx
LAN_INET_DENY_xxx
Logging --> LAN_OUTPUT_DENY_LOG

DMZ_INET_HOST_DENY_xxx
DMZ_INET_DENY_xxx
Logging --> DMZ_OUTPUT_DENY_LOG

Default FORWARD (DROP) Chain
Logging --> FORWARD_DROP_LOG

what specific rule can't we control logging ?

arnova commented 9 years ago

FORWARD_DROP_LOG is too general. Like with the INET stuff we should have _NOLOG variables for LAN->INET stuff as well.

abelbeck commented 9 years ago

So you are proposing new rules something like ?

LAN_INET_HOST_DENY_xxx_NOLOG
LAN_INET_DENY_xxx_NOLOG
DMZ_INET_HOST_DENY_xxx_NOLOG
DMZ_INET_DENY_xxx_NOLOG

Personally, on production systems I run with most all logging disabled, then when looking for something I temporarily enable the related logging and 'grep' for what I'm looking for. With that in mind adding selective 'on' logging rules like:

LAN_INET_HOST_DENY_xxx_LOG
LAN_INET_DENY_xxx_LOG
DMZ_INET_HOST_DENY_xxx_LOG
DMZ_INET_DENY_xxx_LOG

would allow selective logging to occur while the global logging is disabled. This approach would be much more straightforward to implement as well.

Possibly an example where _NOLOG is particularly useful ?

arnova commented 9 years ago

Well it's legacy and since we already use it in other places, might as well stick to it. I don't see any particular advantage/disadvantage of either implementation except for consistency (+legacy).

abelbeck commented 9 years ago

Well, you added _NOLOG a few years ago :-)

I think (for this topic) it is worth thinking how it would be used and whether _NOLOG or _LOG logic is the most convenient to users.

I hope we both agree that we need to keep the LAN_OUTPUT_DENY_LOG, etc. global variables working as they are today. If so, that makes _NOLOG more troublesome to implement.

abelbeck commented 9 years ago

Thinking about this more...

Arno, back when you started this wonderful project, most every packet was interesting and the default was to log all blocked packets. As such if logs were coming from the same host and were annoying to see, you could disable them with _NOLOG, fine.

Fast forward to today, I would suggest the exact opposite is the case... most every blocked packet is not interesting and they come at such a rate many users disable logging where possible. Only in special cases would a log be useful, and the logic of _LOG would be the more natural rule to use.

arnova commented 9 years ago

A drawback is that it would break backwards compatibility. Not sure what approach feels more "natural" anyway, need to think about it.

abelbeck commented 9 years ago

We could have a mix of _NOLOG (original) and _LOG (new stuff) without breaking backwards compatibility.