The SDK based applications are compatible with other software, using various methods for transparent filtering TCP traffic: LSP, sockets hook, TDI or NDIS redirectors. The toolkit is protected from the filtering conflicts, when several local proxies are filtering the same TCP connections in cycle.

NetFilter SDK consists of two subsystems: TDI-level TCP redirector (kernel driver) and FiltersLib C++ library.

TDI-level driver for redirecting the outgoing TCP connections to local or remote proxy.

The driver uses redirection rules for redirecting TCP connections to the local or remote addresses. Each redirection rule defines a set of filtering parameters:

- A range of remote IP addresses
- Remote port
- Process identifier (PID)

The outgoing TCP connections, which suit the rule parameters, are redirected to the specified IP endpoint. The local proxy is able to determine the original remote address after accepting the redirected connection.

The driver supports any number of client processes. Each process can provide its own set of redirection rules and implement a proxy for handling the redirected connections. The rules in driver are associated with the owner process identifiers. If some connection suits the rules of several driver client processes using the local proxies for filtering connections, the driver builds a filtering chain and redirects the connection to each proxy according to their order in rules list.

TDI redirector driver can be used for building TCP filtering applications. The filtering works transparently for the end user, because it is not necessary to make any changes in the settings of network applications.

The TDI-level driver approach requires less system resources than the methods based on LSP or sockets hooks. It does not need executing any code in the address space of filtered applications, so it is more compatible with the anti-virus and anti-spyware applications.

API library with simple interface is used for interaction with the driver.

The driver works on all existing Windows operating systems:
Win9x/ME/2000/XP/2003/Vista, including 64-bit versions of XP/2003/Vista.

Limitations:
- IPv6 is not supported.
- The driver filters only on \Device\Tcp. It is possible for traffic to bypass the filtering if the raw sockets interface or RawIp device is used.
- The driver must be signed with a digital certificate to work properly on Vista x64.

FiltersLib: C++ library for filtering TCP connections.

This library works with TDI redirector and allows filtering the outgoing TCP connections. The driver redirects connections to the local address of high-performance proxy, implemented in FiltersLib. The proxy parses the incoming and outgoing data and allows filtering HTTP, POP3, SMTP and other protocols in convenient way.

- HTTP parser supports filtering HTTP/1.0 and HTTP/1.1 protocols. The client requests and server responses are decoded for filtering in client application. The parser automatically decodes the compressed content (GZip, deflated) and the content in chunked transfer encoding. The parser encodes the content back to the original encoding after filtering it in client application.

- POP3 parser decodes the protocol and returns the downloaded messages as objects with decoded content. The parser automatically decodes the content in Base64, Uuencode and Quoted-printable encodings. The filtered content is encoded back to original encoding. The protection from timeouts is implemented in POP3 filter to avoid the timeouts in email client during downloading large email messages.

- SMTP parser decodes the protocol and returns the outgoing messages in the same decoded format as for POP3. It is possible to block the transmission of particular messages by returning the error code with status string to the email client. The protection from timeouts is implemented to avoid the server timeouts during filtering the email messages.

The proxy may also return the transmitted content in a raw format.

This combination TDI redirector + FiltersLib proxy is protected from conflicts with other filters in system. The transparent proxies with no such protection may filter the same connection in cycle, hooking the remote connections of each other.

Several filtering flags are available for optimizing the filtering in particular cases:

- Deferred remote connections. The proxy doesn’t establish connection with remote server until receiving the first outgoing packet from client application when this flag is enabled for some session. This flag is useful when the client application emulates server responses. For example, it is possible to use this flag for implementing a caching HTTP proxy.

- Read-only mode for the incoming and outgoing content. By default the parsers of HTTP, POP3 and SMTP protocols don’t send the data to client or server until receiving the full client request or server response. It is required, because in most cases it is not possible to decode and filter the transmitted content in packet mode. But if the client application doesn’t change the incoming or outgoing data, it is possible to avoid the transmission delays and make the proxy to send the received data immediately. The client application is still receiving the content in decoded format in this mode, but it can’t send it back to proxy because the packets are already sent to client or server. For example, this mode is useful for implementing TCP monitors, because they don’t change the data.

- The negation flag. This flag allows excluding from filtering the connections with specified parameters. For example, it is possible to avoid filtering for connections with remote IP address from the specified range, with certain remote port or established by the process with given identifier.

>> Download the DEMO

>> Buy the sources