Thank you for posting this question. Firewall threat messages could possibly be attacks, but not necessarily as they could also be caused by misconfigurations or peculiarities in the network. In AOS, threats have been categorized and been assigned a weight based on their possible severity. Threats with a higher severity have the potential to be more compromising to hosts behind the firewall than threats with a lower severity.
The threat you have displayed above is a minor threat, and virtually can be ignored. You can disable this message from appearing on the CLI, per session, by issuing the no events command. For future reference I have detailed this particular threat below, as described in our IPv4 Firewall Protection in AOS guide:
Short Definition: Reassembly timeout
Description: Indicates that the fragments necessary to complete reassembly
have not arrived in a timely manner. An attacker could have attempted to
consume all of the resources in the reassembly engine of a server or other
Action: The reassembly engine drops the offending fragments and frees the
I hope this makes sense, but please do not hesitate to reply to this discussion with further information or questions. I will be happy to assist you in any way I can.
I marked this question as "assumed answered," but please feel free to reply if you have further questions on this topic.
2 questions, 1) what is the timeout value? and 2) is there a way to increase this value? or alternatively 2b) is there a way to disable this check?
I stumbled in here looking for something else. Then did a quick detour out of curiosity.
Sorry I don't know the answers to your specific questions, (I'm fairly certain Support will say the timer isn't programmable). I don't think you'd want to disable a firewall check and resulting resource clean up..
You may long since have discovered an issue, but if the messages were consistently related to the source 220.127.116.11 as shown in your example, then my quick internet search shows people were using that as a DNS server. (Perhaps at Covad).
So perhaps it was slow completing DNS responses and causing fragmented responses to time out. (people were complaining about it's performance).
Changing DNS servers would have been a good test at that time. there are some good public DNS servers out there. (I've used 18.104.22.168 in the past)
...moving on with my original search
Cheers - Glen