Personal Firewall-middle-tier NDIS middle-tier driver sending and receiving process

1) User Configuration (User-mode).

There are three ways to intercept network packets in the User state: Winsocklayeredserviceprovider (LSP), Windows2000 packet filtering interface, and the Winsock Dynamic Connection library with the replacement system. The most deadly disadvantage of packet interception in the user state is that it can only be done at the Winsock level, while the packets for the underlying protocol in the network protocol stack cannot be processed. Therefore, these methods are not suitable for personal firewalls.

2) kernel State (Kernel-mode).

   a) TDI filter Driver (tdifilterdriver).

when an application is sending or receiving a network packet, it is done with the interface provided by the protocol driver. Protocol drivers provide a set of system-predefined standard interfaces to interact with applications. Therefore, it is necessary to develop a filtering driver to intercept these interfaces, so that network packet interception can be achieved. When an application sends or receives a network packet, it is done through the interface provided by the protocol driver. Protocol drivers provide a set of system-predefined standard interfaces to interact with applications. Under Windows2000/nt, IP,TCP,UDP is implemented in a driver, Called Tcp.sys, this driver created 5 devices: Devicerawip,deviceudp,devicetcp,deviceip,devicemulticast. All of the network data operations of the application are carried out through these devices. Therefore, we only need to develop a filtering driver to intercept these interactions of the interface, we can achieve network packet interception. In addition, the network data interception of the TDI layer can also get the process details of Operation network packet, which is also an important function of personal firewall. However, the TDI transport driver has a flaw that tdifilterdriver belongs to Upperdriver, On Tcpip.sys, this means that packets received and processed by Tcpip.sys are not routed to the upper layer, and some received packets, such as ICMP packets, cannot be filtered. The ICMP response packet is generated and responded directly by Tcpip.sys, and the above filter driver is completely unknown. In addition, this method needs to write the driver at the core layer of the system, which requires the writer to be familiar with the working mechanism of the core layer of Windows operation, and the driver is very high in code quality, which can cause the system to crash with a slight carelessness,

b) win2kfilter-hookdriver. This is a driver from the Windows2000 system, which is primarily used to intercept network packets using the functionality provided by Ipfiltdrv.sys. The structure of the filter-hookdriver is very simple and easy to implement. But because its structure is too simple and relies on ipfiltdrv.sys,microsoft, it is not recommended to use Filter-hookdriver.

Personal Firewall Atlas

c) ndishookdriver. This method is non-public under WINDOWS2000/XP, so this method is more dependent on the platform, it needs to judge different operating system versions in the program and use different methods.

D) NDIS Middle-tier driver (Ndisintermediatedriver). NDIS (Networkdriverinterfacespecification) is the short name for the network Driver Interface specification developed by Microsoft and 3Com, which supports the following three types of network drivers: miniport drivers, Middle-tier drivers (Intermediatedriver) and protocol drivers. The middle-tier driver is between the protocol layer drive and the small port driver, it is very powerful, can provide a variety of services, be able to intercept all network packets (Ethernet frames), filter the miniport driver, to achieve a specific protocol or other functions such as packet encryption, authentication and so on. To sum up, in the NDIS middle Layer Network packet interception method structure specification, powerful, this technology is very suitable for personal firewalls.

Internal structure of the middle-tier driver (NDIS)

NDIS supports 3 drivers: micro-port driver, middle-tier driver, and protocol driver.

1) micro-port driver. is the network card driver, which is responsible for managing the network card, including sending and receiving data through the network card, it also provides interface for the upper driver.

2) middle-tier driver. It is typically located between the miniport driver and the transport Protocol driver, and is based on the driver between the link layer and the network layer, because the middle tier drives the middle tier in the drive hierarchy, it must communicate with its upper layer protocol and the downlevel miniport driver, and export the functions of the two protocols. Although the middle-tier driver exports the MINIPORTXX function, it does not really manage the physical network card, but instead exports one or more virtual adapters, the upper layer protocol can be bound to the above. For protocol drivers, the middle-tier exported virtual adapter looks like a physical NIC, and when it sends packets or requests to the virtual adapter, the middle-tier driver propagates the packets and requests to the downlevel miniport driver, and when the lower-level miniport driver indicates the receiving packet or state, The middle-tier driver goes up to the protocol driver on the bound virtual adapter. The primary role of the middle-tier driver is to filter packets, which has the advantage of intercepting all network packets.

3) protocol-driven, i.e. network protocol. It is located at the highest level of the NDIS system and is often used as the lowest driver in the transport driver that implements the transport protocol stack. Transport protocol-driven request packets are copied from the sending application to the packet, and the packets are sent to the lower driver by invoking the NDIS function. The protocol driver also provides a protocol interface to receive packets from lower-level drivers. The transport protocol driver passes the received packets to the appropriate client application. On the lower level, the protocol driver interacts with the middle-tier miniport driver. The protocol driver calls the NDISXX function to send packets, read and set the underlying driver maintenance information, and use the operating system services. The protocol driver also exports a series of entry points, which NDIS calls to indicate the acceptance of the packet, indicate the status of the underlying drive, or communicate with other protocol-driven traffic.

Workflow within the middle tier

1) Middle-tier management of data packets

The middle-tier driver receives a packet descriptor from a high-level driver and sends it over the network, which is associated with one or more chained data buffers. The middle-tier driver is able to repackage the data and use the new packet descriptor for data transfer, or it can pass the packet directly to the low-level driver, and if the driver's lower bounds are non-connected, call the Ndissend or Ndissendpackets function to complete the function. If the lower boundary of the driver is connection-oriented, call the Ndiscosendpackets function to complete this function. The middle-tier driver can also do some things to change the contents of a chain buffer, or to adjust the sending order or timing of incoming packets relative to other send tasks. However, even if the middle-tier driver simply passes the incoming datagram in the lower layer, for example, simply counting the packets, you must assign a new packet descriptor and manage some or all of the new package structure.

Each middle-tier driver must assign its own package descriptor instead of a high-level packet descriptor. If the middle-tier driver wants to convert a packet from one format to another, the buffer descriptor must be assigned to map the buffer used to replicate the transfer data, which is allocated by the middle-tier driver. If you have OOB data related to the copied package descriptor, you can copy the data to the new OOB data block associated with the package descriptor (the middle-tier driver assignment) by first obtaining a pointer to the OOB data area with the Ndis_oob_data_from_packet macro, and then Call Dismovememory to move its contents into the OOB data area associated with the new package descriptor. The driver can also use the NDIS_GET_PACKET_XXX or NDIS_SET_PACKET_XXX macro to read related content from the OOB data area associated with the old package descriptor and write the OOB data area associated with the new package descriptor.

The package descriptor is assigned by calling the following NDIS function

A) call Ndisallocatepacketpool or Ndisallocatepacketpoolex to assign and initialize a set of non-paged pools for a fixed-size package descriptor (specified by the caller).

b) Call the Ndisallocatepacket function to allocate the package descriptor from the pool allocated by Ndisallocatepacketpool (EX). Depending on the purpose of the middle-tier driver, the driver is able to repackage the buffers that introduce the package descriptor connections. For example, the middle-tier driver can allocate the package buffer pool and repackage the ingest package data in the next case. If the middle-tier driver receives a data buffer from a high-level protocol driver that is larger than the single buffer that the lower media can send, the middle-tier driver must split the incoming data buffer into smaller, A data buffer that satisfies low-level sending requirements. The middle-tier driver can change the length of the incoming packet by compressing or encrypting the data before it forwards the sending task to the low-level driver. Call the following NDIS function to allocate the required buffers above:

Ndisallocatebufferpool gets the handle used to allocate the buffer descriptor;

Ndisallocatememory or Ndisallocatememorywithtag allocating buffers;

c) Call Ndisallocatebuffer assign and set buffer descriptor, mapped by ndisallocatememory (Withtag) allocates a buffer and links it to the Ndisallocatepacket assigned package descriptor. The driver can link the buffer descriptor and the package descriptor by calling the Ndischainbufferatback or Ndischainbufferatfront function. Call Ndisallocatememory (Withtag) returns the virtual address and buffer length that will be passed to the Ndisallocatebuffer function to initialize its mapped buffer descriptor. Package descriptors that meet the typical requirements can be allocated on demand when the driver is initialized, or by Protocolbindadapter function calls. If necessary or for performance reasons, the middle-tier driver developer can allocate a certain number of package descriptors and buffers mapped by buffer descriptors during the initialization phase, so that resources are pre-allocated for protocolreceive to replicate the incoming data (which will be directed to the high-level driver). The incoming send packets are also passed to the adjacent low-level driver for miniportsend or Miniportsendpackets, and the available descriptors and buffers are prepared. If the last buffered actual data length is smaller than the length of the buffer when the middle-tier driver replicates the receive/send data to one or more buffers, the middle-tier driver calls Ndisadjustbufferlength to adjust the buffer descriptor to the actual length of the data. When the package returns to the middle-tier driver, the function should be called again to adjust its length to the actual size of the full buffer.

2) workflow for the lower boundary for a non-connected middle-tier driver

With the Protocolreceivepacket function, incoming data is received from the low-level NIC driver as a full packet, specified by the package descriptor of the Ndis_packet type, or by indicating the inline data to the protocolreceive function. and copies the data to the packets provided by the middle-tier driver. The bottom-facing connection-oriented middle-tier driver always uses the Protocolcoreceivepacket function to receive data from a lower-level NIC driver as a complete packet.

The middle-tier driver retains ownership of the received packet in the following cases: when the current boundary targets a non-connected middle-tier driver to indicate a full packet to the Protocolreceivepacket function, The current boundary-oriented middle-tier driver directs the packet to the Protocolcoreceivepacket function, where Dis_packet_oob_data's STATUS member is set to any value other than ndis_status_resources. In these cases, the middle-tier driver retains ownership of the package descriptor and the resources it describes until the received data is processed and calls the Ndisreturnpackets function to return the resources to the lower driver. If Protocolreceivepacket passes the resources it receives to the high-level driver, at a minimum, the package descriptor should be substituted with the package descriptor already assigned by the middle-tier driver. Depending on the purpose of the middle-tier driver, there are several different package management policies when it receives the full packet from the low-level driver. For example, here are several possible package management policies: Copy buffer contents into a buffer that is allocated by the middle-tier driver, which is mapped and linked to a new package descriptor, returns the input package descriptor to the lower-level driver, and then directs the new packet to the upper driver, creates a new package descriptor, Link the buffer (associated with the indicated package descriptor) to the new package descriptor, and then instruct the new package descriptor to the high-level driver. When the high-level driver returns the package descriptor, the middle-tier driver must remove the link between the buffer and the package descriptor, link the buffers to the package descriptor that was originally received from the lower-layer driver, and finally return the original package descriptor and the resource described to the lower-layer driver. The Protocolreceivepacket function is also available even if the lower boundary targets a non-connected middle-tier driver that supports the protocolreceive function. When the low-level driver does not release ownership of the resource indicated by the package descriptor, NDIS invokes the Protocolreceive function, and when such a situation occurs, the middle-tier driver must replicate the received data into its own buffer. For a connection-oriented middle-tier driver for the bottom boundary, when the lower-level driver does not release ownership of the resource indicated by the package descriptor, the Ndis_packet_oob_data STATUS member of the packet is set to Ndis_status_resources. The driver's Protocolcoreceivepacket function must then copy the received data into its own buffer

5" principle of the middle-tier drive filtering packets

The NDIS middle-tier driver plays an interface function in NDIS that forwards packets sent by the upper-layer driver and sends it to the lower-level driver. When a middle-tier driver receives a packet from a downlevel driver, it either calls the Ndismxxxindicatereceive function, Either call the Ndismindicatereceivepacket function to indicate to the upper layer that the packet middle-tier driver opens and establishes a binding to the low-level NIC driver or NDIS middle-tier driver by calling NDIS. The middle-tier driver provides the miniportsetinformation and miniportqueryinformation functions to handle the setup and query requests of high-level drivers, and in some cases, may also pass these requests to the lower NDIS driver. This functionality can be implemented by calling Nidsrequest if its lower boundary is oriented to no-connection, and if its lower boundary is connection-oriented, it is implemented by calling Nidscorequest. The middle-tier driver sends packets to the network low-level NDIS driver by invoking the functions provided by NDIS. For example, the lower boundary for a non-connected middle-tier driver must call Ndissend or ndissendpackets to send a packet or an array of packets, and ndiscosendpackets must be called to send the packet array packet in the case of the lower boundary facing the connection. If the middle-tier driver is based on a non-ndisnic driver, the sending interface will be opaque to NDIS after calling the Miniportsend or miniport (Co) sendpackets function of the middle-tier driver. NDIS provides a set of NDISXXX functions and macros that hide the details of the lower operating system. For example, a middle-tier driver can call Ndisminitializetimer to create a synchronous clock, and you can call Ndisinitializelisthead to create a linked list. The middle-tier driver uses a function that complies with the NDIS standard to increase its portability on Microsoft operating systems that support the Win32 interface.

In the design of the firewall, the core part should be the filtering of the packet.

Other functions are built on the basis of packet filtering, such as intrusion detection and message detection, based on packet filtering. Packet filtering is mainly the analysis of the IP header, for example: In the Ethernet, the resulting datagram is roughly the following structure, the Ethernet frame head 14 bytes, placed in the PUCHAR structure array of the No. 0 element to the 13th element, where the first six bytes is the destination MAC address, and then six bytes source MAC address, Then two bytes is the protocol type, the usual protocol type is 0X080X00->IP,0X080X06->ARP,0X080X35->RARP, so the protocol type can be judged by the 12th element and the 13th element of the array. The filter rules are built on this basis. If you want to filter a specific protocol, just read the data in the corresponding byte, determine whether the rules to be filtered can be, of course, the actual filtering rules are much more complex, such as the specified port to specify the IP filter.

Personal Firewall-middle-tier NDIS middle-tier driver sending and receiving process