Network Monitoring

The task was to write a tool to access the application network traffic for its further analysis for the Windows NT5 platform and higher.

It is one of the common tasks for the Corporate Security Systems. Solutions here differ by the level of monitoring, amount of data available for monitoring, analysis tools, system performance etc.

Initial Conditions

It was necessary to implement the driver that got the access to the network traffic and also a mechanism that allowed filtering network packages for the different applications and then transporting obtained data to the user-level program to parse and analyze them.

Solution variants

A sniffer of network packages can be implemented at two levels: TDI ( Transport Driver Interface) and NDIS (Network Driver Interface Specification).

One of the solution variants was to use an open-source project Tdi_fw as a base but cut it to the light-weight TDI driver. However the research exposed a number of problems: complexity of the mentioned project, presence of insufficient amount of bugs in particular in the work with SMB packages.

The next variant was a driver that worked at the both TDI and NDIS levels simultaneously. TDI level let to get the handler of application that sent a package, NDIS level (which a famous project Ethereal works on) let to get direct access to all of packages without limitations.

However we had to reject this variant too. The first difficulty was that NDIS was poorly documented that made it hard to find and fix bugs. The second minus was that we obtained «raw» network traffic at NSID level. It meant that we had to implement also the assembling of TCP and UDP packages which body could come in different parts in any sequence. Another negative factor was that the functioning at two levels simultaneously could cause many problems.

Finally it was decided to choose the solution on TDI level, that made it possible to avoid implementation of operations of the low-level roughing-out of network traffic.

Result

Last variant was implemented. Even after the complete stabilizing of TDI level we got the «lost» packages problem however. It appeared to be the result of non-trivial bug. To get all packages it is not enough to monitor only outgoing connections. For example, even for monitoring of such application as Yahoo which connects to an external server, we had to additionally watch the incoming connections.

One of the most complex tasks was to determine the user-level application that sent the packages. All incoming and some outgoing packages do not have a context of paternal application (for example it is not always possible to learn a parent process if it was already completed). The driver for process activity monitoring was implemented to solve this task. It stores its own handler map for the started processes and opened sockets. It helps to associate send and receive operations with the process.

The solution for Windows Vista appeared to be much easier. We used filtering of network traffic via WFP (Windows Filtering Platform). fwpkclnt.sys driver was used to get access to WFP. This platform provides the full range of tools for watching network threads and parent process context detection. Thus all user-level applications on Vista can be monitored via WFP. The TDI part was also included to the solution for the support of old applications that worked directly with TDI for example by means of their own driver.

Although the solution is implemented there are a number of interesting unsolved tasks. We can mention the encrypted connections for example. It is impossible to decode the intercepted packages if applications use, for example, Diffie-Hellman mechanism of key exchange. This problem can be solved by middle level attack but it will require additional scale changes in application functioning scheme.