How to log *ONLY* DENY/REJECT packets in ufw

This documentation could be what you are looking for : https://help.ubuntu.com/community/UFW
This shows deny access configuration syntax.
 Documentation for the man pages : http://manpages.ubuntu.com/manpages/eoan/en/man8/ufw.8.html

Here is what I could find. I will yield this answer to @ Manfred Hampl or @ actionparsnip they are better at command line configuration than I am.

I have looked at those links. The documentation does not explain how to configure ufw/gufw to log only DENY/REJECT packets.

I have tried many combinations of the logging and loglevel options, referencing those pages for guidance, along with the man page. I still have not figured out how to accomplish this.

BTW Answer #687400 is one of the very reasons I am having difficulty figuring this out.

In line with what I wrote in https://answers.launchpad.net/ubuntu/+source/ufw/+question/687400 it seems to me that you have to set the default policy to "allow" to achieve what you want (i.e. not logging those packets that are allowed).

Maybe the following is working:
set a default policy of allow
set a general rule to deny or reject everything
set specific rules to allow those packets that you want to pass the firewall
set logging to low

General remark: In my opinion your approach to log only those packets that are denied does not make much sense. From a security point of view the critical ones are those that are allowed. Those that are denied or rejected are not worth bothering about, because they are blocked anyhow.

I do not want to ALLOW the packets. I want to NOT log packets that are not ALLOWED.

ufw and gufw generally deny incoming packets without me even having to set anything. From there, the UI enables me to permit certain connections as an exception to the chain policy. Any packets not meeting those constraints get denied by default. At least, this appears to be the default mode of operation. I was not seeking to radically change the way the gufw UI works. This is simply a request to log the packets that are denied.

I was trying to work with the UI as is. If the intent of typical usage is to change the table policy to ALLOW and deny individual cases, that is not too clear or obvious. I think the current approach is fine and suitable.

I am interested in finding out why I receive packets that ultimately are not allowed. If packets are being denied or rejected, then there is some problem. If packets are being allowed, I assume that some rule in the input chain permitted it to get past the firewall, meaning it did not break any rules and that packet is OK.

Dang. No way to edit these posts. Let me restate the first paragraph of my previous post:

I want to NOT log packets that ARE allowed.

Maybe this question/issue could be better explained as follows: Is there a way that ufw/gufw could enable logging on the default policy (meaning, the chain itself)? This is possible with iptables, but the ufw doc do not seem to have that as an option. This way, I could disable logging on all rules in a chain and just have all defaulting packets get logged. I hope maybe this will make more sense.

Also, maybe I should elaborate on the specific issue. If my firewall allows packets through, then they are going to a port in a running server or client program of some kind. I expect that these are normal and desirable. The receiving program will handle the packets from there. I won't allow packets through to a program except from the source they are supposed to come from, if any, by the rules in the chain.

It's the packets that attempt to get through but are DROP'd because there are no matching rules allowing them through that are of real interest to me. I may want to investigate why those are being sent to my firewall from outside.

https://wiki.ubuntu.com/BasicSecurity/Firewall

Advanced Functionality

As mentioned, the ufw application is capable of doing anything that iptables can do. This is achieved by using several sets of rules files, which are nothing more than iptables-restore compatible text files. Fine-tuning ufw and/or adding additional iptables commands not offered via the ufw command is a matter of editing various text files1:

    /etc/default/ufw: high level configuration, such as default policies, IPv6 support and kernel modules to use

    /etc/ufw/before[6].rules: rules in these files are evaluated before any rules added via the ufw command

    /etc/ufw/after[6].rules: rules in these files are evaluated after any rules added via the ufw command

    /etc/ufw/sysctl.conf: kernel network tunables

    /var/lib/ufw/user[6].rules or /lib/ufw/user[6].rules (0.28 and later): rules added via the ufw command (should not normally be edited by hand)

    /etc/ufw/ufw.conf: sets whether or not ufw is enabled on boot, and in 9.04 (ufw 0.27) and later, sets the LOGLEVEL

    /etc/ufw/after.init: initialization customization script run after ufw is initialized (ufw 0.34 and later)

    /etc/ufw/before.init: initialization customization script run before ufw is initialized (ufw 0.34 and later)
  *** --> After modifying any of the above files, activate the new settings with:
                        $ sudo ufw disable
                       $ sudo ufw enable
****You must re- enable your firewall after all the settings to establish the changes *** Then restart computer **

https://wiki.ubuntu.com/UncomplicatedFirewall

A solution would be to simply add the functionality to ufw/gufw. For example, in the GUI, there could be an option switch next to the default policy for each of the 3 chains to enable logging. Possibly a pull-down, allowing the user to set similar logging levels as for individual rules.

I would think this would not be a difficult change to make, given the above information telling me how to do it. Then the feature would be available to everyone, a feature which I am certain many people (such as myself) would use. Not everyone in the world desires to ignore potentially errant packets coming from the outside world, especially if that "outside world" happens to be the local network (as is the case with my own here).

Thanks.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.