Open arnova opened 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 ?
FORWARD_DROP_LOG is too general. Like with the INET stuff we should have _NOLOG variables for LAN->INET stuff as well.
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 ?
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).
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.
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.
A drawback is that it would break backwards compatibility. Not sure what approach feels more "natural" anyway, need to think about it.
We could have a mix of _NOLOG (original) and _LOG (new stuff) without breaking backwards compatibility.
lan-inet rules should have nolog settings for reject/deny