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

FS#1545 - Firewall unnecessarily logging connection closes #6498

Open
openwrt-bot opened this issue May 12, 2018 · 0 comments
Open

FS#1545 - Firewall unnecessarily logging connection closes #6498

openwrt-bot opened this issue May 12, 2018 · 0 comments
Labels

Comments

@openwrt-bot
Copy link

pprindeville:

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.

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

No branches or pull requests

1 participant