IMD-based package filter firewall principle and implementation by PiggyXP [Pig]

xiaoxiao2021-03-06  59

First, in the foreword, IMD intermediate layer technology introduction, PASSTHRU routine analysis four, some demo code 5 Data reporting principle and implementation ", 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, the intermediate layer drive technology introduces the intermediate layer driver, English is NDIS Intermediate Driver. 1) Introduction of the intra-core network driver introduces the three basic kernel-level network drivers. The three-layer DRIVER sequence is: 1. MiniPort nic drivers: micro-port network card driver, located in the bottom, directly manipulate the network card And provide 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, is the network interface used by most programs. 2) IMD drove the IMD intermediate layer, its substance is 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 Upper Edge and Protocolxxx Functions At Its Lower Edge. (See the DDK Document) Intermediate layer Insert Network and protocol layer, the protocol layer above is characterized by a virtual micro-port network card Structure, and the next NIC appears as 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) In front of IMD package filtering technology, we have seen that all datamines have to pass through the intermediate layer, so we can join the feature of the datagram we want to filter in the middle layer, and implement intermediate-level-driven kernel-level package filtering .

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, you may have already wanted to see how to achieve an IMD-based package filter firewall, however, you will definitely hesitate, if we let us write the whole middle layer driver, is it a bit too difficult? What? 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 demonstration code Our purpose is to perform our filter code when calling the data report 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 following code to get the entire datagram: // ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ----------------------------- int ppacketsize; puchar pbuf; uint buflength; mdl * pnext; uint i; // the contents of a packet is copied 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; // Remove IF (pnext == null) Break; NdisqueryBuffersafe (PNEXT, & PBUF, & BUFLLENGTH, 32); NDISMOVEMEMORY (PPacketContent i, Pbuf, buflength; i = buflength;} // data copy is completed // ------------------------------- ------------------------ Now, we have obtained the contents of the datagram in the PTReceive function, stored in PPACKETCONTENT, the datagram format you can Go to the book.

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 report rule uint IGMP = 0; / / IGMP Data Report Rule UINT TCP = 0; // TCP Data Report Rule UINT UDP = 0; // UDP Data Report Rule // Rules Determined 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 (PPacket NDIS_STATUS_NOT_ACCEPTED;}}} {ac (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;}}}}}} (udp == 1) {IF ((char *) PPACKETCONTENT [12] == 8 && ((char *) PPACKETCONTENT [13] == 0 && ((char *) PPACKETCONTENT [23] == 17) {DBGPRINT ("

UDP is intercepted! / N "); NdisfreeMemory (PPacket Ndis_status_not_accepted;}} // ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------- here, the ptreceive function has been modified, as long as the PTReceive function is called When you receive a datagram, you can perform our rules. Change the PTReceivePacket function below. In fact, the above modification code content is the same, but the ptreceivepacket function is not only like the PTReceive function, PTReceivePacket is directly in the entrance parameters. Pndis_packet structure Packet, stores all the contents of the datagram, so you can directly stick the above code to the code of the function PTreceivePacket. To now, whether it is a network card call which receive functions, you 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 so simple. In fact, in PPACKETCONTENT has got all of the datagrams, we can extend the rules at will For example, filtering the specified IP, the specified port datag report, as for which position should be set, you only have to find a book to introduce the data architecture, you know, huh, huh. Five, drive compilation and installation Many, actually talking about the implementation and driving code of the IMD package, but I have modified code, how to compile and install? This part solves the problem of driving compilation and installation. We use the PASSTHRU code to receive data The part has made modifications. 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 to the PASSTHRU directory to compile PASSTHRU. .sys file, then go to the NTDDK / SRC / Network / Config / Filter directory, execute build -cz to get sfilter.dll, and then add Netsf.inf and Netsf_m .inf under the PASSTHRU directory, a total of four files. This way, drive installation The files needed 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. Six. Summary is rare I wrote 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. Specially recommended to drive development network (www.driverdevelop.com) Forum NDIS network interface development version, here is the highest in the domestic level, all of all 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.netposted on May 27, 2004 11:28 am

转载请注明原文地址:https://www.9cbs.com/read-113655.html

New Post(0)