Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lan-inet nolog settings #16

Open
arnova opened this issue Mar 20, 2015 · 8 comments
Open

lan-inet nolog settings #16

arnova opened this issue Mar 20, 2015 · 8 comments

Comments

@arnova
Copy link
Contributor

arnova commented Mar 20, 2015

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

@abelbeck
Copy link
Contributor

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
Copy link
Contributor Author

arnova commented Mar 20, 2015

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

@abelbeck
Copy link
Contributor

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
Copy link
Contributor Author

arnova commented Mar 20, 2015

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

arnova commented Mar 23, 2015

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

@abelbeck
Copy link
Contributor

abelbeck commented Jun 8, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants