Iphone and IOS devices detected originating Tcp & Fin Flood

As a network administrator we have noticed repeated network latency events which are caused by Iphone / IOS devices identified as originating TCP and Fin Flood network traffic (short bursts of thousands of packets per sec) to Apple and Akamai IP destinations. We do not have any indication of a SYN attack. Any insight on this type of behavior would be helpful and is anyone seeing this on their network?

Posted on Feb 23, 2023 09:25 AM

Reply

Similar questions

5 replies

Feb 23, 2023 09:49 AM in response to tiredeli

SonicWall and likely other vendors have had problems with spurious TCP FIN flood detections (SonicWall notice of spurious detections), other firewalls I've worked with have certainly had issues with dropped packets during connection close and other firewall-instigated connection shenanigans, making determinations here more difficult many FIN floods are spoofed, which in aggregate means you're going to need to do some more digging including for the TCP ports involved, for relevant firmware revisions and updates, details of the network layout, etc., and probably also mirroring the relevant switch ports to see if this activity is real or is a mis-detection. Probably also want to work with the support vendor for the gear that is detecting this. Flaky network gear can cause TCP to become less than stable and to start retransmitting traffic, too.

Feb 23, 2023 12:22 PM in response to MrHoffman

Right on the money- I know that article well and we have been investigating it with Sonicwall support for several weeks, but they insist that the firewall is just reporting what its seeing. I am trying to get to the bottom of the actual network latency when this happens, however I have not been able to capture packets when it happens. I do have a current capture setup on a "repeat offender" workstation, however have not been able to catch it in the act. It is most often another device. I have updated firmware across the board. We have been monitoring the switches as well for Collision and discarded packets.

Feb 23, 2023 01:13 PM in response to tiredeli

I'd mirror the firewall switch port off into a packet capture box, seeking to independently confirm or deny the report.


The packet capture box on the mirrored port can be configured to log just FIN traffic here, depending on your ISP link activity and the speed of the capture box.


Or I'd replace the firewall. Zyxel and Ubiquiti are locally popular choices for their low-mid-range networking gear.

Feb 24, 2023 06:21 AM in response to tiredeli

Any of these network and security investigations starts out with a signal. The fundamental question with that signal? Is the signal truthful, or is it fiction? Am I chasing an actual event, or am I chasing something else? Am I chasing, well, nothing?


One of the major network vendors was reporting fictional switch port states, which meant checking the link directly for its duplex settings, and too often manually configuring duplex. They got auto-negotiation wrong. Tooling can be wrong. Too many folks around here have accepted what anti-malware told them without consideration, and—in a recent false-positive case around here—macOS was blocking the anti-malware from deleting part of and corrupting macOS, while the users of that anti-malware were persisting in trying to delete part of macOS due to that false positive. Gremlins are varied. Every so often I meet a screaming NIC / broadcast storm. There are numerous other examples of tooling errors. And other sorts of gremlins.


Here? SonicWall already has a published history of false signals for this exact case.


Your job here is not to protect the honor of any particular tool, it’s to monitor your network, and which also inherently means monitoring your own tools. Trust, but verify. Mirror the switch port for the SonicWall box, and see if SonicWall is actually seeing what it claims.


Finding spoofed stuff tends to mean mirroring ports throughout the network, too; segment-level instrumentation to locate the source segment(s) for the spoofing.


You may well be getting a real FIN flood here, or some instability from some other component within your network, or some other glitch being reported as a FIN flood, but I’d expect a bit more chatter around the ’net if this were a generic FIN flood issue with any particular vendor’s gear. Mirror the port.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Iphone and IOS devices detected originating Tcp & Fin Flood

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.