I. Introduction
Second, IMD intermediate layer technology introduction
Third, PASSTHRU routine analysis
Fourth, some demo code
V. Drive compilation and installation
Summary
I. Introduction
Some time ago, I saw the "SPI-based datagram and implementation" written by Too2y friends on the security focus. It is very good. The SPI-based data report intercept technology mentioned in the article is in user-level. User-level interception has its advantages, convenient, easy to transplant, strong versatility, but user-level does not get all the datagrams. The IMD-based datagram filtration mentioned herein belongs to the kernel level, which is built on the network drive.
In fact, I wanted this article two months agolus. Unfortunately, this technology was done a year ago. I haven't used it for a long time, so I haven't written it. However, there is a matter of recent problems, involving the intermediate layer driver. So, I lost a year of DDK and licking it. During this time, I really would like to thank Linxder's help, let me walk less, otherwise, I really have to learn from my head. Not much nonsense, cut into the topic.
Second, intermediate drive technology introduction
Intermediate layer drive, English is NDIS Intermediate Driver.
1) Introduction to the internal nuclear level network
Microsoft Windows 2000 supports three basic kernel-level network drivers. The three-layer DRIVER sequence is:
1. MiniPort Nic Drivers: Micro-port NIC drive, located at the bottom, directly manipulate the network card and provides an interface to the high-level drive.
2. Intermediate drivers: IMD intermediate layer driver, this is the protagonist, located between 1 and 3, and the specific role will be introduced.
3. Protocol Drivers: High-level protocol driver, commonly known as TDI (transmission driver interface), above two layers, directly for user-level,
Providing network services for users, that is, the network interfaces used by most programs.
2) IMD driver
The IMD intermediate layer, its substance is very simple, the most classic description is below:
An Intermediate Driver IS Typically Layered Over One or More Ndis Nic Drivers and Under a Transport Driver (Possibly Multilayered) That Supports TDI At Its Upper Edge.
An NDIS Intermediate Driver Exports MiniPortxxx Functions At ITS Upper Edge and Protocolxxx Functions At Its Lower Edge. (See DDK Document)
The intermediate layer is inserted between the NIC and the protocol layer, and the above protocol layer appears as a virtual micro-port network card structure, and the next network card is characterized by a structure of a protocol layer. Therefore, whether it is a network card to receive and upload a datagram, or the upper layer is delivered to the NIC transmission, there is no exception to pass through the intermediate layer.
3) IMD package filtering technology
As we have seen, all the datamines must pass through the intermediate layer, so we can add the feature of the datagram we want to filter in the middle layer, and implement the intermediate-driven kernel level package filter.
This is very obvious, first of all, doing filtering at the driving level, no need to group, fast, efficiency is high; secondly, all the duty has no exception, as long as the data reported by the NIC can be intercepted, avoid User-level cannot get the shortcomings of all datagrams. Of course, there is no perfect thing in the world. The IMD package filtering technology also has its inevitable disadvantages, close to the operating system version, with hardware, low portability. When I debug this driver, I met countless blue screen, countless times restart, and entered a few security mode, and even reinstalled the system. It is because of some of the above problems. Now there is still no manufacturer to launch an IMD-based practical firewall, most of them are works in the laboratory, maybe it is very difficult to do, but I still hope to see such products as soon as possible.
Third, PASSTHRU code analysis
Here, you may have already wanted to see how to realize the IMD-based package filter firewall, but you will definitely hesitate. If you let us write the whole middle layer driver, is it a little too hard? Moreover, I am just a network security. I am not specifically written, let me complete a driver, but also to disguise a network card on the upper protocol, and disguise into a protocol layer for the lower layer. Is this not a thing?
Oh, in fact, Microsoft is very nice. After this technology, the DDK comes with an intermediate-driven routine is PASSTHRU. The PASSTHRU implements the basic function of an intermediate layer, and the pair is expressed as a protocol layer driver, and the PASSTHRU driver is installed, you can see a virtual network card in the network card in hardware management. However, the PASSTHRU is just inserted into the network card and the upper level agreement, but it does not do anything, that is, the PASSTHRU just flows throughout the data. We want to implement the function of the intermediate package filtering, you need to modify the PassthRu.
Think about the feature of the package we want to implement, we only need to perform rule judgment when the intermediate layer is received, and in the PASSTHRU, the received datagram is PTRECEIVE and PTRECEIVEPACKET in the protocol.c file. Two functions are implemented. According to Microsoft's explanation, Microsoft recommends receiving the PTReceivePacket function, because you can get higher efficiency, however, in order to be compatible, the PTReceive function is also preserved to use the old NIC. So, on a single network card, only one function is working, it depends on your network card model. Ingenious, my two machine network card applications are different. Also IBM machine, a P4 1.5G machine network card is Realtek RTL8139 (a) PCI Fast Ethernet Adapter, another P4 2.0G machine network card is Intel (r) Pro / 100 Ve NetWork Connection, where Realtek The network card is PTReceive to pick up, and the Intel's network card is to pick with PTReceivePacket.
Now we know which function is responsible for receiving a datagram, then we can modify this function. From compatibility and versatility, we need to modify the PTReceive and PTReceivePacket functions, where plus the rules we need to determine are filtered, and the detailed code is posted below.
Fourth, some demo code
Our aim is to perform our filter code when calling the received datagram function, so we have to add our own code in the function code, and use the data newspapers that filter specific protocol types to make a demonstration. First modify PTReceive, look at the code in the protocol.c file, the code is used to get a pndis_packet structure Packet in the code, and the data report is stored in the linked list in this structure. We define a PuChar structure PPACKETCONTENT, then use the code below to get the entire dataset:
/ / -------------------------------------------------------------------------------------------- ---------
Int packetsize;
Puchar PPACKETCONTENT;
Puchar PBUF;
Uint buflength;
MDL * PNEXT;
UINT I;
// Copy the package from the Packet to PPACKETCONTENT
NdisQueryPacket (Packet, Null, Null, Null, & Packetsize);
Status = NDISAllocateMemory (& PpacketContent, 2000, 0, HighestacceptableMax);
IF (status! = ndis_status_success) Return Status;
NDiszeromeMory (PPacketContent, 2000);
NdisQueryBuffersafe (Packet-> Private.Head, & Pbuf, & Buflength, 32);
NDISMOVEMEMORY (PPacketContent, PBUF, BUFLENGTH);
i = buflength;
PNEXT = packet-> private.head;
For (;;)
{
IF (pnext == packet-> private.tail)
Break;
PNEXT = PNEXT-> Next; / / Movement
IF (PNEXT == NULL)
Break;
NdisQueryBuffersafe (PNEXT, & PBUF, & BUFLLENGTH, 32);
NDISMOVEMEMORY (PPacketContent i, PBUF, BUFLLENGTH);
i = buflength;
}
// Data copy is completed
/ / -------------------------------------------------------------------------------------------- ---------
Now, we have got the contents of the datagram in the PTReceive function, stored in PPACKETCONTENT, and your datagram is in the format. Typically, in the Ethernet, the obtained datagram is substantially the following structure, and 14 bytes of the header header, placed in PPACKETCONTENT [0] to PPACKETCONTENT [13], where the first six bytes are the destination MAC address, then six One-word source MAC address, then two bytes are protocol types, usual protocol types are 0x08 0x00 -> IP, 0x08 0x06 -> ARP, 0x08 0x35 -> RARP, so, you can pass PPACKETCONTENT [12] and PPACKETCONTENT [ 13] To determine the type of protocol. If it is an IP package, then the PPacketContent is stored in the IP header. According to the IP header format, you can get the 23rd byte PPACKETCONTENT [23] to represent the transport layer protocol: 1-> ICMP, 2-> IGMP, 6 -> TCP , 17-> UDP, the rest is the content of the data. Because we just do demonstrations, just know that these signs are fine, others can expand according to your needs. We can do some rules through the contents of PPacketContent, such as filtering the ICMP package, we only need to compare PPACKETCONTENT [12] and PPACKETCONTENT [13] and PPACKETCONTENT [23] These three flags can be, if not ICMP package, then Do any work, if you match, then return a ndis_status_not_accepted, discard the package, release the PPACKETCONTENT, you can filter the ICMP package, below is the code of the filtering rule. / / -------------------------------------------------------------------------------------------- ---------
// Rule flag (1 means filtration, 0 means release, you can configure rules by changing this value)
UINT ICMP = 1; // ICMP Data Reporting Rules
UINT IGMP = 0; // IGMP Data Report Rules
UINT TCP = 0; // TCP Data Report Rules
UINT UDP = 0; // UDP Data Report Rules
// rule judgment
IF (ICMP == 1)
{
IF ((char *) PPACKETCONTENT [12] == 8 &&
((char *) PPACKETCONTENT [13] == 0 &&
((char *) PPACKETCONTENT [23] == 1)
{
DBGPRINT ("ICMP is intercepted! / N");
NDISFREEMEMORY (PPacketContent, 2000, 0);
RETURN NDIS_STATUS_NOT_ACCEPTED;
}
}
IF (IGMP == 1)
{
IF ((char *) PPACKETCONTENT [12] == 8 &&
((char *) PPACKETCONTENT [13] == 0 &&
((char *) PPACKETCONTENT [23] == 2)
{
DBGPRINT ("IGMP is intercepted! / N");
NdisfreeMemory (PPACKETCONTENT, 2000, 0); RETURN NDIS_STATUS_NOT_ACCEPTED;
}
}
IF (TCP == 1)
{
IF ((char *) PPACKETCONTENT [12] == 8 &&
((char *) PPACKETCONTENT [13] == 0 &&
((char *) PPACKETCONTENT [23] == 6)
{
DBGPRINT ("TCP is intercepted! / N");
NDISFREEMEMORY (PPacketContent, 2000, 0);
RETURN NDIS_STATUS_NOT_ACCEPTED;
}
}
IF (udp == 1)
{
IF ((char *) PPACKETCONTENT [12] == 8 &&
((char *) PPACKETCONTENT [13] == 0 &&
((char *) PPACKETCONTENT [23] == 17)
{
DBGPRINT ("UDP is intercepted! / N");
NDISFREEMEMORY (PPacketContent, 2000, 0);
RETURN NDIS_STATUS_NOT_ACCEPTED;
}
}
// Rules judge end
/ / -------------------------------------------------------------------------------------------- ---------
Here, the PTReceive function has been modified, as long as the PTReceive function is called, we can perform our rules. The PTReceivePacket function can be modified, in fact, the above modification code content is the same, but the ptreceivepacket function is followed by PTReceive functions Not too, PTReceivePacket has received the PNDIS_PACKET's structure Packet directly in the entrance parameters, and all contents of the datagram are stored, so it is possible to stick the above code to the code of the function PTReceivePacket. To now, whether it is a network card call which receive functions, we can perform the rules we need.
In fact, the rules defined above are very simple, because only as a demonstration, and my topic, 嘿嘿, it is not that simple. In fact, in PPACKETCONTENT has got all of the datagram, we can extend the rules at will. For example, filtering the specified IP, specifying the datagram, as for which location should be set, you only have to find a book to introduce the data architecture, you will know, huh, huh.
V. Drive compilation and installation
As so much in the previous, it is actually the implementation and driver code of the IMD package, but I have modified the code, how to compile and install?
This part solves the problem of driving compilation and installation. We use the PASSTHRU code to modify the part of the received datagram. Then we compile with the Builder tools comes with DDK. I usually use the free build environment in the DDK program group in the Start menu, and execute build -cz in the PASSTHRU directory to compile the PASSTHRU, get the passthru.sys file, then go to the NTDDK / SRC / Network / Config / Filter directory, execute Build -cz gets sfilter.dll, then adds Netsf.inf and Netsf_M.inf under the PASSTHRU directory, four files. In this way, the files needed to drive installation are all. Open the network properties, add a service, find the passthru directory, install, pop up no digital signature warning, ignore, continue to install, and finally, you will find that the network properties add a component called Sample Filter, at the same time, hardware management A Sample Filter MiniPort is added to the network card in the server. If you have already arrive here, and the system does not have a blue screen and crash, so congratulations, you have successfully installed the intermediate layer driver, and has already played a package filtering.
Summary
It's hard to write so much, now make a summary. The code in the above, I am just used to do demo, only to explain the IMD-based package filter firewall principle and implementation, there are many work that needs to be done, there will be a lot of problems that drive above, and often accompanying It is a blue screen, crash, and even reload the system.
You may ask, then every time I change the rule, do you have to install it again? Moreover, you must restart once, the old driver is completely uninstalled, more trouble. Oh, it is actually the intermediate layer drive is to combine with the application layer. First, you have to specify a rule in the drive, and the application of the application layer can control the driver's rule flag bit in the DEVICEIOCONTROL passing the instruction to the driver.
Special recommendation drive development network (
Www.driverDevelop.com) The NDIS network interface development version of the forum, here is the highest in the domestic level, all of the issues related to the driver you can get resolved there.
Finally, with the presentation, the preparation of the processing system will be prepared before commissioning, and any system problems, the problem is good, I don't have any responsibility, huh, huh.
Welcome to our team's site: 711 Network Security Group
http://www.cpyy.net
