[FS#1545] Firewall unnecessarily logging connection closes

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - Philip Prindeville (pprindeville) 

Attached to Project - OpenWrt/LEDE Project
Summary - Firewall unnecessarily logging connection closes
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - Supply the following if possible:
 - Device problem occurs on

x86_64, generic (in this case, Supermicro SYS-5018D-FN8T)

 - Software versions of OpenWrt/LEDE release, packages, etc.

OpenWrt master

 - Steps to reproduce
   
This is fairly easy.  A while back (around 1997) Sun (which then was the go-to manufacturer for Web servers) decided that a clean 2-way close of a socket (including quiet-time) was too time consuming and that in an effort to be able to cycle through the 5-tuple space more quickly (i.e. in under 250 seconds... keep in mind we were still using HTTP 1.0 back then which didn't allow connection reuse) they'd do a RESET on the connection to circumvent the clean shutdown and quiet-time.

Well, it worked, and now lots of servers tend to do a RESET on the connection.  Some still do a 2-way close...

The problem is that this confuses NAT state on firewalls, which drop the connection information as soon as they see the outbound (since it's closer it's usually seen first) RESET packet, but then they see the inbound reset and they're confused because they've already dropped the state associated with the connection.  Or else the firewall sees the outbound FIN, ACK but doesn't bother to wait for the FIN at this point before deleting NAT state, since it's the server's problem if he doesn't get it...

If they held onto it (connection state) for a couple of seconds, then it would make more sense... but it would also interfere with cycling through the 5-tuple space quickly.  So they can't.

As a result (you were wondering when I was going to get to the point, right?  I know I was...), you end up seeing a lot of these harmless but annoying messages in your logs:

May 12 10:54:09 OpenWrt3 kernel: [481026.650247] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0x00 PREC=0x00 TTL=54 ID=30282 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK PSH URGP=0 
May 12 10:54:09 OpenWrt3 kernel: [481026.700207] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=30283 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK FIN URGP=0 
May 12 10:54:09 OpenWrt3 kernel: [481026.984519] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=30284 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK FIN URGP=0 
May 12 10:54:10 OpenWrt3 kernel: [481027.855512] DROP(src wan): IN=eth5 OUT= SRC=17.249.44.10 DST=66.232.81.197 LEN=117 TOS=0x00 PREC=0x00 TTL=54 ID=30285 DF PROTO=TCP SPT=443 DPT=49664 WINDOW=235 RES=0x00 ACK PSH FIN URGP=0 


For UDP, there's so connection state so messages related to packets which can't get admitted will always be logged.  That's fine, and most traffic isn't UDP anyway, so that's not a problem.

But for TCP, logging incoming connection attempts or obviously wrong connection state makes sense... but do we need to log sloppy connection closes?

Can we filter out FIN packets?  I guess that would leave us unaware of stealth scans, but I can't think of a better solution... especially on boxes with limited persistent logging resources.


More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=1545