SonicWall Log Shows Possible FIN Floods

10/14/2021 70 People found this article helpful 212,670 Views

Description

Resolution

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

Navigate to Investigate | Logs | Event Logs entries show possible FIN Flood as shown below:

01/14/2011 08:08:04.368 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - src: 192.168.104.136:49449 dst: 68.142.214.24:80 - -
01/14/2011 08:08:05.432 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - from machine xx:xx:5e:eb:dd:f3 with FIN rate of 305/sec has ceased - -

The Source and destination IP addresses continue to change in the FIN Flood log messages.

Fin Flood Definition: The Attacker will flood out packets with spoofed source addresses, spoof ports and FIN flag is set to on. If the attacker could guess sequence numbers, port combinations and source address of an existing flow then the attack could end valid data sessions; however, this is very unlikely. Most likely, the attacker is using the FIN Flood to bypass security systems that would block other packet types. The attacker’s goal is to overwhelm the network or end host with excess packets to deny service.

Procedure

The first step in analyzing an attack such as this is to check the Investigate | Logs | Event Logs page on the SonicWall security appliance to determine if the attack is active and to gather information.
Save the log files and check any other recently saved log files. An easy way to do this is to save the log files in comma separated form. Then save a copy of the file in a different location. In the copy of the file, delete all non FIN Flood entries.
Next combine all the FIN Flood entries into a single file. In the case of this attack, the FIN Floods had been occurring for several months so the combined text file was 25 pages.

EXAMPLE: An example of those entries are shown below:
01/14/2011 08:17:57.928 - Alert - Intrusion Prevention -      Possible FIN Flood on IF X0 - src: 192.168.104.136:49754 dst: 209.85.225.105:80
01/14/2011 08:18:03.176 - Alert - Intrusion Prevention -      Possible FIN Flood on IF X0 - from machine xx:xx:5e:eb:dd:f3 with FIN rate of 309/sec has ceased

NOTE: The rate of packets was as high as 1320 per second; fortunately on the SonicWall Log | Category page  Log Redundancy Filter was configured to only show each unique log entry once every 60 seconds (which is default). Otherwise the log would have filled up in seconds.
The next step was to analyze the log entries.
The internal IP addresses were DHCP lease on the LAN network.
The external IP addresses were common Internet sites such as Google, Facebook, etc as shown below.
- dst: 209.85.225.191:80 Google
- dst: 209.85.225.105:80 Google
- dst: 209.85.225.93:80 Google
- dst: 65.55.17.39:80 msn
- dst: 209.85.225.139:80 - rate: 1320/sec Google
- dst: 66.220.147.11:80 - rate: 621/sec Facebook
- dst: 66.220.147.33:80 - rate: 1081/sec Facebook
- dst: 209.85.225.101:80 - rate: 665/sec Google
- dst: 69.63.181.15:80 - rate: 1088/sec Facebook
- dst: 74.125.227.45:80 - Google
The entries were all originating inside the network on the LAN out to the Internet. The FIN Floods were only lasting 5-6 seconds. This site was a school and the student Internet access was limited to only sites in the Allowed Domains list. All the destinations addresses in the FIN Flood entries were being blocked by SonicWall Content Filtering Service.
Here is what was happening - some clients are using programs (streaming client in Messenger?) that are automatically trying to open many HTTP sites which are blocked by CFS. The client's Three way handshake (TCP/SYN/ACK) sequence with the server and been killed with an RST packet; the client then sends TCP FINs packets to the blocked Internet destinations. This is happening so fast that it generates the 'possible FIN attack' alerts.
The System | Diagnostic page‘s Connection Monitor showed a normal level of the connections; this was expected since the connections were not being completed..
The next step in a problem such as this is go to the computer and check the system for bad programs or scan for worms, Trojans or bots. The school had active updated anti-virus on the computers and the student computers were automatically reimaged each night. In this case, it was a process the students were doing.
To identify the application causing the problem, a packet capture can be ran on the System | Packet Monitor Page (or System | Packet Capture page on older firmware). However, this is difficult in this case since the FIN Floods were random and only lasted seconds. A capture can be left running to try to catch a FIN Flood, configured as follows:
- Settings:
  Navigate to Investigate | Packet Monitor | Configure, Enable checkbox: Wrap Capture Buffer Once Full.
- Monitor Filter
  
  Ether type: IP
  IP type: TCP, UDP
  Source IP: IP of one PC's on LAN that has been reoccurring in the log.
  (you want to capture the DNS lookups as well as the HTTP attempts)
- On the Advanced Monitor Filter tab include firewall-generated and intermediate packets.
If you have Alerts setup on Manage | Log Settings | Automation page, then you can configure the Attacks on the Manage | Log Settings | Base Setup page for the alert column. This might aid in alerting you to when a FIN Flood has occurred. Then you can check the packet capture. The capture will periodically fill up and flush throughout the day, even if limited to a single IP.
Once you do get the capture during a FIN Flood, click the stop capture button. Then save the capture by clicking on the Export As drop down menu. Export the capture as a Libpcap format and save again as HTLM format. The Libpcap can be opened in wireshark for quicker viewing. The HTLM format shows the SonicWall interfaces involved.

TIP:If you are using IE7, you will need to click the alert under the address bar to okay active x.
Navigate to Investigate | Packet Monitor , Export as - Libpcap.

NOTE:This information can be used to identify the program causing the FIN Floods so this streaming program can be blocked to avoid future problems.

Resolution for SonicOS 6.2 and Below

The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.

Problem Definition

Log | View entries show possible FIN Flood as shown below:

01/14/2011 08:08:04.368 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - src: 192.168.104.136:49449 dst: 68.142.214.24:80 - -
01/14/2011 08:08:05.432 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - from machine xx:xx:5e:eb:dd:f3 with FIN rate of 305/sec has ceased - -

The Source and destination IP addresses continue to change in the FIN Flood log messages.

Fin Flood Definition: The Attacker will flood out packets with spoofed source addresses, spoof ports and FIN flag is set to on. If the attacker could guess sequence numbers, port combinations and source address of an existing flow then the attack could end valid data sessions; however, this is very unlikely. Most likely, the attacker is using the FIN Flood to bypass security systems that would block other packet types. The attacker’s goal is to overwhelm the network or end host with excess packets to deny service.

Procedure:

The first step in analyzing an attack such as this is to check the Log | View page on the SonicWall Security Appliance to determine if the attack is active and to gather information.
Save the log files and check any other recently saved log files. An easy way to do this is to save the log files in comma separated form. Then save a copy of the file in a different location. In the copy of the file, delete all non FIN Flood entries.
Next combine all the FIN Flood entries into a single file. In the case of this attack, the FIN Floods had been occurring for several months so the combined text file was 25 pages.

EXAMPLE: An example of those entries are shown below.
01/14/2011 08:17:57.928 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - src: 192.168.104.136:49754 dst: 209.85.225.105:80
01/14/2011 08:18:03.176 - Alert - Intrusion Prevention - Possible FIN Flood on IF X0 - from machine xx:xx:5e:eb:dd:f3 with FIN rate of 309/sec has ceased
NOTE: The rate of packets was as high as 1320 per second; fortunately on the SonicWall Log | Category page Log Redundancy Filter was configured to only show each unique log entry once every 60 seconds (which is default). Otherwise the log would have filled up in seconds.
The next step was to analyze the log entries..
The internal IP addresses were DHCP lease on the LAN network.
The external IP addresses were common Internet sites such as Google, Facebook, etc as shown below.
- dst: 209.85.225.191:80 Google
- dst: 209.85.225.105:80 Google
- dst: 209.85.225.93:80 Google
- dst: 65.55.17.39:80 msn
- dst: 209.85.225.139:80 - rate: 1320/sec Google
- dst: 66.220.147.11:80 - rate: 621/sec Facebook
- dst: 66.220.147.33:80 - rate: 1081/sec Facebook
- dst: 209.85.225.101:80 - rate: 665/sec Google
- dst: 69.63.181.15:80 - rate: 1088/sec Facebook
- dst: 74.125.227.45:80 - Google
The entries were all originating inside the network on the LAN out to the Internet. The FIN Floods were only lasting 5-6 seconds. This site was a school and the student Internet access was limited to only sites in the Allowed Domains list. All the destinations addresses in the FIN Flood entries were being blocked by SonicWall Content Filtering Service.
Here is what was happening - some clients are using programs (streaming client in Messenger?) that are automatically trying to open many HTTP sites which are blocked by CFS. The client's Three way handshake (TCP/SYN/ACK) sequence with the server and been killed with an RST packet; the client then sends TCP FINs packets to the blocked Internet destinations. This is happening so fast that it generates the 'possible FIN attack' alerts.
The System | Diagnostic page‘s Connection Monitor showed a normal level of the connections; this was expected since the connections were not being completed..
The next step in a problem such as this is go to the computer and check the system for bad programs or scan for worms, Trojans or bots. The school had active updated anti-virus on the computers and the student computers were automatically reimaged each night. In this case, it was a process the students were doing.\
To identify the application causing the problem, a packet capture can be ran on the System | Packet Monitor Page (or System | Packet Capture page on older firmware). However, this is difficult in this case since the FIN Floods were random and only lasted seconds. A capture can be left running to try to catch a FIN Flood, configured as follows.
- Settings: Enable checkbox: Wrap Capture Buffer Once Full.
- Monitor Filter:
  
  ether type: IP
  IP type: TCP, UDP
  source IP: IP of one PC's on LAN that has been reoccurring in the log.
  (you want to capture the DNS lookups as well as the HTTP attempts)
- On the Advance Monitor Filter tab (Advanced tab in pre 5.8.x.x) include firewall-generated and intermediate packets.
If you have Alerts setup on the Log > Automation page, then you can configure the Attacks on the Log |category page for the alert column. This might aid in alerting you to when a FIN Flood has occurred. Then you can check the packet capture. The capture will periodically fill up and flush throughout the day, even if limited to a single IP.
Once you do get the capture during a FIN Flood, click the stop capture button. Then save the capture by clicking on the Export As drop down menu. Export the capture as a Libpcap format and save again as HTLM format. The Libpcap can be opened in wireshark for quicker viewing. The HTLM format shows the SonicWall interfaces involved.

TIP: If you are using IE7, you will need to click the alert under the address bar to okay active x.

NOTE: This information can be used to identify the program causing the FIN Floods so this streaming program can be blocked to avoid future problems.