Strikeback firestorm

Anthony Nelson, president of ESTec Systems in Edmonton, Alberta, Canada very kindly wrote to me with an interesting response to an article on not striking back against perceived attacks. The following is Nelson’s slightly edited text.

***

Some time ago a firewall called Sidewinder had an option for a _finger_ attack. If you enabled it and the firewall recognized an attack it would initiate a retaliatory finger attack against the originator of the attack.

Two of my clients had purchased Sidewinder firewalls and both had enabled the strikeback feature. The two companies also had a joint venture project going on. An employee from company A was seconded to company B for the duration of the project. When he arrived at company B, he tried to access internal resources at company A as he believed he was allowed to do. It did not work, so he repeatedly tried different ways to do it. At some point in this process, the Sidewinder firewall at company A determined that his activity constituted an attack; it therefore initiated a strikeback. The Sidewinder firewall at company B looked at the strikeback and determined that _it_ was an attack and so it initiated its own strikeback to A’s strikeback.

Both companies at that time were running T-1 lines to the Internet. The firewalls filled the pipe with attack and counterattack, effectively cutting both companies off the ‘Net until an administrator at one of the companies shut down their firewall, ending the data storm.

I was asked to perform the forensic analysis of the event. After reading my report, both companies turned off the strikeback feature.

***

My thanks to Nelson for this excellent example of a data storm. In system engineering terms, the situation exemplifies a positive feedback loop; each component responds with an increased reaction to the response of the other component, and so the problem gets worse and worse.

From a programming standpoint, the situation is similar to a deadly embrace, since each firewall is waiting for the other to stop. The problem cannot be resolved by the firewalls themselves; termination requires external intelligence and intervention.

Finally, in a sense, the problem is a kind of race condition, since it does not occur unless the communicating systems have the misfortune to pick partners with the same configuration (much as in a programming race condition, where a problem doesn’t happen unless two processes interact in a particular sequence and time window).

Keep those interesting cases coming, folks!