Products > Networking & Wireless

[solved] networking, a simple fake FIN package causes a lot of troubles

<< < (5/5)

ejeffrey:

--- Quote from: scatha on March 07, 2019, 09:58:27 am ---
--- Quote from: legacy on March 07, 2019, 09:24:04 am ---Are you sure  :D ?

Tested two from Amazon: wrong assumption :D

--- End quote ---

This is surprising, what makes/models? All enterprise routers and most commodity routers will contain some form of stateful firewall behaviour which (if enabled) will absolutely block TCP traffic which is not part of an already established connection.

--- End quote ---

The "attack" is coming form the LAN side, not going through the firewall.  100% of  NAT routers block unassociated FIN packets simply because it is impossible to not block them -- the only work at all because of connection tracking, and without a connection it doesn't know where to send the FIN.

I still think what is happening is that the server is not calling shutdown() and leaving a lot of sockets in the half-shutdown CLOSE_WAIT state, which is then filling up the file descriptor table or some other finite resource.  But the OP has not shared any diagnostic information, reproducible example, anything other than unintelligible code fragments, or even described what specific software or hardware they are using.  It is a little surprising that busybox's telnet server would have this bug, but entirely possible.  Another possibility, since this is presumably some embedded device is that the kernel data resource limits are set very low either because of the limited system memory or misconfiguration.  Without further information this is just speculation.

westfw:

--- Quote ---
--- Quote ---    Even a home NAT-based router probably wouldn't allow rogue FINs on unestablished connections.

--- End quote ---
Are you sure  :D ?
Tested two from Amazon: wrong assumption

--- End quote ---

You would have to set them up with the "unsecured" network on the "WAN" side, and the "known ok" network on the "LAN" side.
I wouldn't expect it to do the filtering between LAN ports.



--- Quote ---
--- Quote ---    255 (max IP TTL) seconds...

--- End quote ---
    IP does not have any timeouts
    IP TTL is number of hops. At each hop TTL is decreased by one. Yes, it is named badly

--- End quote ---
1) You're wrong.  TTL is a timeout, and IP does have timeouts (packet reassembly timeout.)  It's ALSO a hop count; each router decrements the TTL by at least one.  RFC790 is sort-of seminal.
2) TCP has a concept "Maximum Segment Lifetime" that's intimately related to the chosen IP TTL.  It's the MSL that comes into play for "zombie" connections.
3) I was wrong too.  MSL is apparently considered 2*TTL, and default TTL (in RFC793) was recommended to be one minute.  I'm not sure how that plays out in modern networks - transission times went down and hop counts went up pretty rapidly, and even back in the late 80s most hosts would use 255 as the default TTL, I think.
4) (heh.  RFC793 has some "amusing" bits in it these days...  "even if data rates escalate to 10's of megabits/sec.")


In any cases, this forum of EEs and microcontroller experts isn't the best place to discuss TCP network attacks of embedded unix.   There are a lot of well-known attacks, and most are well documented, with standard mitigation...

Navigation

[0] Message Index

[*] Previous page