Bug 1028144 - No easy way to log dropped packets
No easy way to log dropped packets
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 13:38 EST by Dominique Brazziel
Modified: 2016-02-21 11:31 EST (History)
10 users (show)

See Also:
Fixed In Version: firewalld-0.4.0-2.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-21 11:31:01 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dominique Brazziel 2013-11-07 13:38:23 EST
Description of problem:
No easy way to specify logging for dropped packets.  Rich rule logging only seem to apply in the specific case of a reject or drop, when what is needed is to see
all connection attempts for which an explicit 'allow' has been configured.  Sometimes when configuring a new service one may forget that a port must opened on the firewall (even though after years of administering systems, fail connection attempts are ALWAYS the firewall ha ha), and a dropped packet message 
in '/var/log/messages' or in the audit log would make things immediately apparent.  As it stands now, all drops are silent.

Further complicating the matter is that the 'deny' chain is walked before the 
'allow' chain so that if one adds a -j LOG to the IN_zone_deny chain ALL incoming packets are logged before either allowing or dropping the packet.

Finally, Windows firewall has a simple checkbox to enable this functionality.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  Try to connect to a port or service which has not been explicitly enabled (i.e. vnc-server).
2.  See message on client 'No route to host 113' (in the vnc-server case)
3.

Actual results:


Expected results:
Log message for dropped connection attempt to DPT=5900.

Additional info:
Comment 1 Peter Verthez 2014-05-11 04:26:42 EDT
This would also be needed to interwork with psad: it should be possible to add a -j LOG at the end of the INPUT chain, before the reject rule.  Currently this is only possible by hacking the python scripts.
Comment 2 Dominique Brazziel 2014-05-19 16:52:16 EDT
Thanks for the direction tip (put it just before REJECT).  It wasn't easy, (I took the long way around) but using some rules from the old 'firestarter' package on Debian I managed to wire up a new chain (IN_home_LSI - LSI for 'Log and Stop Input' - 'home' is my default zone) just before the REJECT target.  Here was the sequence of commands (after testing without the '--permanent' flag):

firewall-cmd --direct --permanent --add-chain ipv4 filter IN_home_LSI

firewall-cmd --direct --permanent --add-rule ipv4 filter IN_home_LSI 0 -j LOG

firewall-cmd --direct --permanent --passthrough ipv4 -I INPUT 7 -j IN_home_LSI

Here is the resulting INPUT chain:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
IN_home_LSI  all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

It looks like it is logging packets that didn't get accepted using the rules 
set up in my IN_home_allow zone.  Cleared out dmesg, then attempted to FTP
(which is not allowed), and saw:

IN=wlan0 <* yada yada yada MAC SRC DST yada yada yada *> 
DPT=21 WINDOW=29200 RES=0x00 SYN URGP=0

Looks good.  This also enables me to see that my router is hammering all the machines on my LAN with silly UDP packets for something called USBShare.  I wouldn't have seen that without this facility and if I hadn't run TCPDUMP out
of curosity a couple of days ago.  Logging dropped packets shows a lot about
unnecessary / bad traffic.
Comment 3 Sakari A. Maaranen 2014-09-30 16:31:15 EDT
I need to accept a given port or service for whitelisted sources only, which is trivial. Logging only rejected (or dropped) packets from other sources to the same port or service would be useful, but not easy.
Comment 4 Jaroslav Reznik 2015-03-03 10:11:38 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 5 Fedora Update System 2016-02-04 10:41:41 EST
firewalld-0.4.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
Comment 6 Fedora Update System 2016-02-04 20:23:53 EST
firewalld-0.4.0-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
Comment 7 Fedora Update System 2016-02-08 08:29:29 EST
firewalld-0.4.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
Comment 8 Fedora Update System 2016-02-09 17:28:01 EST
firewalld-0.4.0-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fc0691e6a7
Comment 9 Fedora Update System 2016-02-21 11:30:32 EST
firewalld-0.4.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.