Hi , To analyze / evaluate you basically have 3 options , there are more but without more details it is hard to give 100% viable options . 1. Increase log level outside or connected to iptables ( on same machine obviously ) * turn on logging of invalid packets with "echo 256 > /proc/sys/net/netfilter/nf_conntrack_log_invalid" * session info/logs with "conntrack -E > conntrack.log" . * complete data/logs with "tcpdump -s0 -nnvvi eth0 -w test.%F-%T.pcap -G 10" . Then review data/log file(s) generated the next time the issue occurs , and look for that specific session with same identifiers . 2. Increase log level at the client or the server side to be able to track TCP level sessions ( cannot give specifics as I known not what these systems are , but could be the same as options 1 , other , more or less . ) 3. Increase log level at the application level , on client and/or server maybe this can tell when that session was started and if the session has been IDLE for some time or was broken on one side ( as in some signal was sent asking to end session and such ) In many cases you might have to combinate these 3 options to actually pinpoint an accurate root cause , but from a technical standpoint option 3 is the "favored" options if this is causing issues to start with as the lower numbered options are the lower level ( deeper ) analysis which typically just verifies the issue and does not resolv it or suggest any way how to resolv it ( if this is actually an issue ) SIDE NOTE: I suggest using this in you firewall rules as this is "less obsolete" then how you did , and I also feels it more correctly covers the options better to be really STATEFUL ( not just for TCP ) -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -s 10.0.0.2 -d 10.0.0.1 -p tcp -m tcp --dport 3306 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT Best regards André Paulsberg-Csibi Senior Network Engineer Fault Handling IBM Services AS andre.paulsberg-csibi@xxxxxxxx M +47 9070 5988 -----Original Message----- From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Luescher Claude Sent: 26. april 2017 11:07 To: netfilter@xxxxxxxxxxxxxxx Subject: Getting rid of false ULOG events once and for all Hello, I'm using a similar ruleset since many years on many servers: $FWCMD -A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT $FWCMD -A INPUT -s 10.0.0.2 -d 10.0.0.1 -p tcp -m tcp --dport 3306 --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j ACCEPT $FWCMD -A INPUT -j $UL --ulog-prefix "LAN IN: " $FWCMD -A INPUT -j DROP These are basic stateful firewall rules to allow mysql connections from a sepcific server. However once in a while I always get log events from all the allowed targets such as: Apr 24 11:51:56 mysql LAN IN: IN=eth0 OUT= SRC=10.0.0.2 DST=10.0.0.1 LEN=52 TOS=00 PREC=0x00 TTL=64 ID=22317 PROTO=TCP SPT=28445 DPT=3306 SEQ=1775770220 ACK=2310754247 WINDOW=2048 ACK URGP=0 Apr 24 11:51:56 mysql LAN IN: IN=eth0 OUT= SRC=10.0.0.2 DST=10.0.0.1 LEN=52 TOS=00 PREC=0x00 TTL=64 ID=17183 PROTO=TCP SPT=18431 DPT=3306 SEQ=1985459406 ACK=286608940 WINDOW=2048 ACK URGP=0 What's happening here exactly? Are the packets out of sequence, connection broke up, packets duplicating etc. and how can I remove these false positives from my log files so only the bad traffic which was blocked is showing up? Thank you. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=02%7C01%7C%7C3473b552582e42b7c8cf08d48c86e755%7C40cc2915e2834a2794716bdd7ca4c6e1%7C1%7C0%7C636287958413968580&sdata=9%2FRxnx%2F2XE518OnjyOJm2HvGct3Ctpzh4S6ICkEYn4w%3D&reserved=0 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
