9. SYN Cookie Troubleshooting: Logs

Introduction

In this last article I will add the last piece of information you can check when troubleshooting TCP SYN Cookie attacks, logs. With this information together with all that you have learned until now you should be able to understand how SYN Cookie is behaving and decide if there is any change you should do in your configuration to improve it.

Use cases

LTM SYN Cookie at Global context

Logs when Global SYN Check Threshold or Default Per Virtual Server SYN Check Threshold has been exceeded are similar, so in order to know in which context was SYN Cookie activated you need to focus on specific text in logs. For example, by having below config:

turboflex profile feature                                                   => adc
tmsh list sys db pvasyncookies.enabled                                      => true
tmsh list ltm global-settings connection default-vs-syn-challenge-threshold => 1500  <=
tmsh list ltm global-settings connection global-syn-challenge-threshold     => 2050  <=
tmsh list ltm profile fastl4 syn-cookie-enable                              => enabled

You will get logs similar to the ones below if Global SYN cache has been reached:

Dec 7 03:03:02 B12050-R67-S8 warning tmm9[5507]: 01010055:4: Syncookie embryonic connection counter 2051 exceeded sys threshold 2050
Dec 7 03:03:02 B12050-R67-S8 warning tmm5[5507]: 01010055:4: Syncookie embryonic connection counter 2051 exceeded sys threshold 2050
Dec 7 03:03:02 B12050-R67-S8 notice tmm5[5507]: 01010240:5: Syncookie HW mode activated, server name = /Common/syncookie_test server IP = 10.10.20.212:80, HSB modId = 1
Dec 7 03:03:02 B12050-R67-S8 notice tmm9[5507]: 01010240:5: Syncookie HW mode activated, server name = /Common/syncookie_test server IP = 10.10.20.212:80, HSB modId = 2

As you can notice there are two different messages, the first one informs about Software SYN Cookie being activated at Global context, and the second one tells us that Hardware is offloading SYN Cookie from Software. Since there is a minimum delay before Hardware to start to offload SYN Cookie is expected to see a non zero value for the counter Current SYN Cache stats. See article in this SYN Cookie series for more information about stats.

Global SYN cache value is configured per TMM, so you see in the log that 2050 threshold has been exceeded in the TMM, and therefore SYN Cookie is activated globally in the device. In this specific example the device has two HSBs and BIG-IP decided that tmm9 and tmm5 would activate each one of them this is why we see the logs repeated.

LTM SYN Cookie at Virtual context

For the same configuration example I showed above you will see log similar to one below if Virtual SYN cache has been reached:

Oct 18 02:26:32 I7800-R68-S7 warning tmm[15666]: 01010038:4: Syncookie counter 251 exceeded vip threshold 250 for virtual = 10.10.20.212:80
Oct 18 02:26:32 I7800-R68-S7 notice tmm[15666]: 01010240:5: Syncookie HW mode activated, server name = /Common/wildcardCookie server IP = 10.10.20.212:80, HSB modId = 1
Oct 18 02:26:32 I7800-R68-S7 notice tmm[15666]: 01010240:5: Syncookie HW mode activated, server name = /Common/wildcardCookie server IP = 10.10.20.212:80, HSB modId = 2

Virtual SYN cache value is configured globally meaning that the configured value must be divided among TMMs to know when SYN cookie will be enabled on each TMM. Run below command to see physical number of cores:

tmsh sho sys hard | grep core

In this example device has 6 TMMs, so 1500/6 is 250.

Note that you will see a warning message entry per TMM (I removed 3 log entries in above example order to summarize) and per HSB ID.

Log does not always show the VIP’s IP, it depends on type of VIP. For example in below case:

Oct 17 04:04:54 I7800-R68-S7 warning tmm2[22805]: 01010038:4: Syncookie counter 251 exceeded vip threshold 250 for virtual = 10.10.20.212:80
Oct 17 04:04:54 I7800-R68-S7 warning tmm3[22805]: 01010038:4: Syncookie counter 251 exceeded vip threshold 250 for virtual = 10.10.20.212:80
Oct 17 04:04:55 I7800-R68-S7 notice tmm2[22805]: 01010240:5: Syncookie HW mode activated, server name = /Common/wildcardCookie server IP = 10.10.20.212:80, HSB modId = 1
Oct 17 04:05:51 I7800-R68-S7 notice tmm2[22805]: 01010241:5: Syncookie HW mode exited,   server name = /Common/wildcardCookie server IP = 10.10.20.212:80, HSB modId = 1 from HSB

There is not any virtual configured with destination IP 10.10.20.212. In fact traffic is handled by a wildcard VIP listening on 0.0.0.0/0, this logged IP is the destination IP:Port in the request that triggered SYN Cookie. You can consider this IP as the most probable attacked IP since it was the one that exceeded the threshold, so you can assume there are more attacks to this IP, however attack could have a random destination IPs target.

Important: Per-Virtual SYN Cookie threshold MUST be lower than Global threshold, if you configure Virtual Server threshold higher than Global, or 0, then internally BIG-IP will set SYN Cookie Global threshold equals to Per-Virtual SYN Cookie threshold.

LTM SYN Cookie at VLAN context

Configuration example for triggering LTM SYN Cookie at VLAN context:

turboflex profile feature                                                   => adc
tmsh list sys db pvasyncookies.enabled                                      => true
tmsh list ltm global-settings connection vlan-syn-cookie                    => enabled
tmsh list net vlan hardware-syncookie                                       => [vlan external: 2888]
tmsh list ltm global-settings connection default-vs-syn-challenge-threshold => 0
tmsh list ltm global-settings connection global-syn-challenge-threshold     => 2500

When SYN cookie is triggered you get log:

Oct 17 10:27:23 I7800-R68-S7 notice tmm[15666]: 01010292:5: Hardware syncookie protection activated on VLAN 1160 (syncache:2916 syn flood pkt rate:0)

In this case you will see that information related to virtual servers on this VLAN will show SYN cookie as ‘not activated’ because protection is at VLAN context:

# tmsh show ltm virtual | grep ' status ' -i
 Status                        not-activated
 Status                        not-activated

If you configure SYN Cookie per VLAN but Turboflex adc/security is not provisioned then you will get:

Oct 17 04:39:52 I7800-R68-S7.sin.pslab.local warning mcpd[7643]: 01071859:4: Warning generated : This platform supports Neuron-based Syncookie protection on per VS basis (including wildcard virtual). Please use that feature instead

AFM SYN Cookie at Global context

Main different in AFM default log is that you will not get a message telling you the threshold it has been exceeded, instead log will inform you directly about the context that detected the attack.

Configuration example for triggering AFM SYN Cookie at global context:

turboflex profile feature                                                        => security
tmsh list ltm global-settings connection vlan-syn-cookie                         => enabled
tmsh list net vlan hardware-syncookie  [not compatible with DoS device]
tmsh list sys db pvasyncookies.enabled                                           => true
tmsh list ltm global-settings connection default-vs-syn-challenge-threshold.     => 0
tmsh list ltm global-settings connection global-syn-challenge-threshold          => 2500
tmsh list security dos device-config default-internal-rate-limit (tcp-half-open) => >2500
tmsh list security dos device-config detection-threshold-pps (tcp-half-open)     => 2500
tmsh list ltm profile fastl4 syn-cookie-enable                                   => enabled

AFM Device DoS has preference over LTM Global SYN Cookie, so in above configuration AFM tcp half open vector will be triggered:

Oct 19 02:23:41 I7800-R68-S7 err tmm[23288]: 01010252:3: A Enforced Device DOS attack start was detected for vector TCP half open, Attack ID 1213152658.
Oct 19 02:29:23 I7800-R68-S7 notice tmm[23288]: 01010253:5: A Enforced Device DOS attack has stopped for vector TCP half open, Attack ID 1213152658.

In the example above you can see that there are logs warning you about an attack that started and stopped, but there is not any log showing if attack is mitigated. This is because you have not configured AFM to log to local-syslog (/var/log/ltm). In this situation DoS logs are basic. If you want to see packets dropped or allowed you need to configure specific security log profile.

Be aware that when SYN Cookie is active because Device TCP half open DoS vector’s threshold has been reached then you will not see any Virtual Server showing that SYN Cookie has been activated, as it happens when SYN Cookie VLAN is activated:

SYN Cookies
Status                        not-activated

This is slightly different to LTM Global SYN Cookie, when LTM Global SYN Cookie is enabled BIG-IP will show which specific VIP has SYN Cookie activated (Status Full Hardware/Software).

In case you have configured logging for DoS then you would get logs like these:

Oct 23 03:56:15 I7800-R68-S7 err tmm[21638]: 01010252:3: A Enforced Device DOS attack start was detected for vector TCP half open, Attack ID 69679369.
Oct 23 03:56:15 I7800-R68-S7 info tmm[21638]: 23003138 "Oct 23 2020 03:56:15","10.200.68.7","I7800-R68-S7.sin.pslab.local","Device","","","","","","","TCP half open","69679369","Attack Started","None","0","0","0000000000000000", "Enforced", "Volumetric, Aggregated across all SrcIP's, Device-Wide attack, metric:PPS"
Oct 23 03:56:16 I7800-R68-S7 info tmm[21638]: 23003138 "Oct 23 2020 03:56:16","10.200.68.7","I7800-R68-S7.sin.pslab.local","Device","","","","","","","TCP half open","69679369","Attack Sampled","Drop","3023","43331","0000000000000000", "Enforced", "Volumetric, Aggregated across all SrcIP's, Device-Wide attack, metric:PPS"
Oct 23 03:56:16 I7800-R68-S7 info tmm[21638]: 23003138 "Oct 23 2020 03:56:16","10.200.68.7","I7800-R68-S7.sin.pslab.local","Device","","","","","","","TCP half open","69679369","Attack Sampled","Drop","3017","69710","0000000000000000", "Enforced", "Volumetric, Aggregated across all SrcIP's, Device-Wide attack, metric:PPS”

The meaning of below fields shown in above logs:

"Drop","3023","43331","0000000000000000"
"Drop","3017","69710","0000000000000000"

Are as below:

{action} {dos_packets_received} {dos_packets_dropped} {flow_id}

Where:

{dos_packets_received} - It counts the number of TCP SYNs received for which you have not received the ACK. Also called embryonic SYNs.
{dos_packets_dropped} - It counts the number of TCP syncookies that you have sent for which you have not received valid ACK.

If you see that {dos_packets_received} are high, but {dos_packets_dropped} are 0 or low, then it just means that AFM is responding to SYN packets with SYN cookies and it is receiving correct ACKs from client. Therefore, AFM is not dropping anything. So this could mean that this is not an attack but a traffic peak.

It can happen that you configure a mitigation threshold lower than detection threshold, although you will get a message warning you, you could not realise about it. If this is the case you will not see any log informing you about that there is an attack. This will happen for example with below configuration:

tmsh list ltm global-settings connection global-syn-challenge-threshold          => 3400
tmsh list security dos device-config default-internal-rate-limit (tcp-half-open) => 3000
tmsh list security dos device-config detection-threshold-pps (tcp-half-open)     => 3900
tmsh list ltm profile fastl4 syn-cookie-enable                                   => disabled

Due to this you will see in /var/log/ltm something like:

Oct 23 03:38:12 I7800-R68-S7.sin.pslab.local warning mcpd[10516]: 01071859:4: Warning generated : DOS attack data (tcp-half-open): Since drop limit is less than detection limit, packets dropped below the detection limit rate will not be logged.

AFM SYN Cookie at Virtual context

All information provided in previous use case applies in here, so for below configuration example:

tmsh list ltm global-settings connection global-syn-challenge-threshold                     => 3400
tmsh list security dos device-config default-internal-rate-limit (tcp-half-open)            => 3000
tmsh list security dos device-config detection (tcp-half-open)                              => 3900
list security dos profile SYNCookie dos-network default-internal-rate-limit (tcp-half-open) => 2000
list security dos profile SYNCookie dos-network detection-threshold-pps (tcp-half-open)     => 1900
tmsh list ltm profile fastl4 <name>                                                           => enabled

AFM device SYN Cookie is activated for specific virtual server with security profile applied:

Oct 23 04:10:26 I7800-R68-S7 notice tmm[21638]: 01010240:5: Syncookie HW mode activated, server = 0.0.0.0:0, HSB modId = 1
Oct 23 04:10:26 I7800-R68-S7 notice tmm5[21638]: 01010240:5: Syncookie HW mode activated, server = 0.0.0.0:0, HSB modId = 2
Oct 23 04:10:26 I7800-R68-S7 err tmm3[21638]: 01010252:3: A NETWORK /Common/SYNCookie_Test DOS attack start was detected for vector TCP half open, Attack ID 2147786126.
Oct 23 04:10:28 I7800-R68-S7 info tmm[16005]: 23003156 "10.200.68.7","I7800-R68-S7.sin.pslab.local","Virtual Server","/Common/SYNCookie_Test","Cryptographic SYN Cookie","16973","0","0","0",
Oct 23 04:10:57 I7800-R68-S7 notice tmm5[21638]: 01010253:5: A NETWORK /Common/SYNCookie_Test DOS attack has stopped for vector TCP half open, Attack ID 2147786126.
Oct 23 04:12:46 I7800-R68-S7 notice tmm[21638]: 01010241:5: Syncookie HW mode exited,   server = 0.0.0.0:0, HSB modId = 1 from HSB
Oct 23 04:12:47 I7800-R68-S7 notice tmm5[21638]: 01010241:5: Syncookie HW mode exited,   server = 0.0.0.0:0, HSB modId = 2 from HSB

Troubleshooting steps

When you need to troubleshoot how device is working against a SYN flood attack there are some steps you can follow.

Check configuration to make a global idea of what should happen when SYN flood occurs:

tmsh show sys turboflex profile feature
tmsh list ltm global-settings connection vlan-syn-cookie 
tmsh list net vlan hardware-syncookie 
tmsh list sys db pvasyncookies.enabled 
tmsh list ltm global-settings connection default-vs-syn-challenge-threshold 
tmsh list ltm global-settings connection global-syn-challenge-threshold
tmsh list ltm profile fastl4 syn-cookie-enable
tmsh list ltm profile tcp all-properties | grep -E 'profile|syn-cookie' 
tmsh list ltm profile fastl4 all-properties| grep -E 'profile|syn-cookie'
list security dos device-config syn-cookie-whitelist syn-cookie-dsr-flow-reset-by tscookie-vlans
tmsh list security dos device-config dos-device-config | grep -A23 half
tmsh list security dos profile dos-network {<profile> { network-attack-vector { tcp-half-open } } }

*I can miss some commands since I cannot know specific configuration you are using, but above list can give you a good idea about what you have actually configured in your system.

Are you using Hardware or Software SYN cookie? Are you using CMP or vCMP? Is device a Neuron platform?
Is SYN cookie configured/working in AFM, in LTM or in both?
Is SYN cookie enabled at Device, VLAN or Virtual Server context?
If issue is at virtual server context, which virtual servers are affected? is the problem happening in a Standard or FastL4 VIP, …?
Check logs (date/times) and stats to confirm what it has really happened and since when.
Take captures to confirm your findings.
Is this an attack? Were there other attacks at the same time (TCP BAD ACK, TCP RST maybe)?
Are thresholds correctly configured attending to expected amount of traffic?
If clients are hidden by a proxy maybe you could save resources by configuring Challenge and remember.
If this is a Neuron platform, is there any error in /var/log/neurond?
Check published IDs related to SYN Cookie for specific TMOS versions or/and platforms.

Conclusion

Now you have enough information to start troubleshooting your own BIG-IP devices if any issue happens, and also and maybe more important you have tools to create the most appropriate configuration attending to your specific platform and traffic patterns. So you can start to take the advantage of your knowledge to improve performance of your device when under TCP SYN flood attack.

Updated Dec 09, 2022

Version 2.0

series-syn-cookie-the-definitive-guide

SYN Cookie

troubleshooting