Best Practices

The best practices provided here will help you create more efficient application filters.

Registration for Events

• Register for as small a set of events as possible. This is true for first-phase events registered in IFWXFilter::FilterInit and for events registered in IFWXFilter::AttachToSession. Unnecessary event registrations increase the load on the Firewall service and reduce performance.
• In IFWXFilter::AttachToSession, don't define explicit data filters unless monitoring or modification of the stream is really needed. This allows the Firewall service to do the data pumping in kernel mode, which is more efficient than the user-mode data pumping of data filters.

Buffers and Data

• Copying data reduces performance, so avoid copying I/O buffer content. Instead, use the methods of the IFWXIOBuffer interface to manage data buffers. To avoid copying buffers, a filter should call IFWXSocket::Recv, specifying NULL as the buffer. This causes the Firewall service to pass to the filter an existing buffer, instead of copying from the existing buffer to the filter's buffer.

Threading

• If your filter performs asynchronous I/O on operating-system files, use the completion notification mechanism provided by ISA. For more information, see Completion Notification Objects.
• Call the IFWXFirewall::StartHeavyBlockingOperation method before making a blocking operation. When this method is used, the Firewall service keeps track of the number of threads that are busy with blocking operations and creates new threads when necessary.
• Do not call IFWXFirewall::StartHeavyBlockingOperation before waiting for a critical section or a resource on which other threads are likely to be blocked. If the newly created thread is blocked on the same critical section, there will be greater congestion on the critical section and more context switches, resulting in an overall reduction in performance.
• Expect methods to be called from different threads simultaneously. If more than one thread accesses data at the same time, the data can be left in an inconsistent state. You can prevent this by using critical sections, which allow only one thread at a time to use the protected code section. Examples of the use of critical sections can be seen in the sample application filters provided with the ISA SDK. For more information on critical sections, see MSDN.
• Similarly, you can use interlocked functions, which synchronize access to a variable that is shared by multiple threads. Interlocked functions prevent a thread from being preempted when it is in the middle of incrementing or checking a variable. For more information on critical sections, see MSDN.
• In general, when calling a method of an object that may call back the calling object (either on the same thread or by waiting for another thread to perform the callback), a deadlock may arise. Therefore, avoid holding locks while calling methods of Firewall service-implemented objects.

  For example, there may be a race between calls to Detach (IFWXDataFilter::Detach, or IFWXSessionFilter::Detach) and other methods. Data filters receive IFWXSocket interfaces when the IFWXDataFilter::SetSockets API is called. Because the Firewall service is multithreaded, more than one thread can use the same IFWXSocket interface simultaneously. Furthermore, one thread may call Detach to release the IFWXSocket interface, while the other thread still attempts to access the interface, perhaps while doing a data-pump. Access to the interface should be protected by a locking mechanism, such as a critical section. Because of locking by the Firewall service, deadlock situations may arise; for example, the following code can lead to a deadlock situation:

  Lock();
  HRESULT hr = spSocket->Close(FALSE);
  Unlock();   
  

  To avoid the deadlock, use this code:

  // Copy member pointer to interface to a local "smart" pointer
  // while the object is locked
  CComPtr<IFWXSocket> spSocket;
  Lock();
  spSocket = m_InternalSocket;
  Unlock();   // lock released to avoid deadlocks
   
  // Must verify that interface was not released by Detach()
  if (spSocket != NULL) {
  // Here it is safe to send, receive or close the socket.
  HRESULT hr = spSocket->Close(FALSE);
  }
  

• Avoid creating too many threads in the Firewall service. If you create a thread that waits for an infrequent event, such as a configuration change, use the Win32 function RegisterWaitForSingleObject. If you create a thread to perform periodic tasks that will spend most of its time sleeping, use the Win32 function CreateTimerQueueTimer. Each of these functions uses thread pools to reduce the number of threads that are busy at one time.

Security for Secondary and Emulated Connections

There are situations in which an application filter is responsible for limiting what IP addresses are allowed access to, including:

• The case of a secondary inbound connection, as occurs in use of the FTP protocol.
• The case of a secondary or emulated connection in a publishing scenario.

For security purposes, the application filter has to define a range of IP addresses for which a particular connection is allowed. Define that range of IP addresses by using the IFWXIpFilter interface.

Note  If you set the range of IP addresses equal to NULL, you are allowing all addresses to connect.