- This topic has 2 replies, 3 voices, and was last updated 15 years, 3 months ago by
.
-
Posts
-
SerpentFly, thanks so much for developing this software. It’s nice to know someone as knowledgable as you is around to answer questions.
After working with the NdisApi functions and following the examples, I have a few questions. First, I’ll tell you how I plan to use your product, in case I’m way off base in my goals.
My main goal is to create a deep packet inspection proxy to protect one of my game servers. As you know, sending malformed packets to some game servers causes issues if the game server doesn’t have the protections in-built. I’m not attempting to do a full-blown DPI firewall or IDS. I just want to be able to analyze INCOMING packet content UDP packets going to specific ports, and based on that analysis, either drop the packet or let it pass thru to the game server. I don’t care about the outgoing packets; I want to just let them pass from the game server to the network interface without hinderance.
In summary, the route of the incoming packets would be:
* UDP packets are received from the outside world and passed through to my game game server via an external firewall port forwarding rule, as normal for gaming servers.
* My DPI proxy sits on the same machine as my game server and intercepts these specific UDP packets and applies simple rules, like checking if an even or odd number of payload bytes, and compares payload to a “bad payload” file, similar to a virus signature file, etc.
* If the UDP packet payload is deemed bad, I drop the UDP packet. If the packet payload is deemed OK, I let it pass to the game server unmodified.
* Any UDP packets sent back out from my game server are not to be intercepted by my DPI proxy; they are to go straight out unchecked.So, after playing around with your product, I believe it can do all of this with ease, if I know how to implement it correctly. I have a few questions:
1) According to the above scenario, can I use your WinpkFilter 3.x product to do it?
2) Can I set a specific device adapter filter so that ONLY UDP packets going to a specific port are grabbed via a ReadPacket() call?
3) Can I use the “listen” mode to grab the packets, and signal to DROP bad packets but let the good ones pass through? I really don’t want to have to re-send the good packets to the loopback address or use tunneling mode. I’d like to just drop the bad packets and let things be as normal for the good packets.
4) Can I open up multiple device adapter handles and set different filters for them so that simultaneous ReadPacket() calls return different packets based on the different filters?
5) Is there a way to not have to keep calling the ReadPacket() method inside of a loop? Like, set the adapter to execute a callback function when a new packet is on the buffer? This would support an event driven model which is much more efficient on the CPU.
6) After reviewing your product documentation, I noticed there is no structure documentation for the Adapter structure that is used commonly throughout your product as an Integer Pointer Handle. You have all the other structures documented, why not this very important one? I figured it must be a common structure in NDIS, but after some research, I’m finding that driver developers start adding their custom fields to it. What is the WinpkFilter structure associated with individual Adapter handles, i.e “_ETH_REQUEST.hAdapterHandle” ?
I hope I’ve been thorough enough for you to understand exactly what I’m trying to do so that you can answer precisely. You know this stuff inside-out SerpentFly, so I bet you know the exact answers and can offer additional recommendations. Thanks in advance.
~Cozmik
this topic is so nice,give our so much problems to thinking~~
admin,can u help us to answer these questions?
1) According to the above scenario, can I use your WinpkFilter 3.x product to do it?
Sure you can.
2) Can I set a specific device adapter filter so that ONLY UDP packets going to a specific port are grabbed via a ReadPacket() call?
Yes, you can use built-in WinpkFilter filters for this.
3) Can I use the “listen” mode to grab the packets, and signal to DROP bad packets but let the good ones pass through? I really don’t want to have to re-send the good packets to the loopback address or use tunneling mode. I’d like to just drop the bad packets and let things be as normal for the good packets.
No, if you suppose to drop packets you should be filtering in tunnel mode. Listen mode only gives you a copy of the packet while passing the original one.
4) Can I open up multiple device adapter handles and set different filters for them so that simultaneous ReadPacket() calls return different packets based on the different filters?
Yes, you can open multiply adapters and set adapter specific filters.
5) Is there a way to not have to keep calling the ReadPacket() method inside of a loop? Like, set the adapter to execute a callback function when a new packet is on the buffer? This would support an event driven model which is much more efficient on the CPU.
Driver code can’t callback user mode code. If to be precise, you can execute a code in user mode part of the memory, but it can’t be safe (as packets arrive from the network at IRQL_DISPATCH_LEVEL but user mode memory can be paged out) and it also would be a security hole (as user mode code is executed with kernel mode privilege).
6) After reviewing your product documentation, I noticed there is no structure documentation for the Adapter structure that is used commonly throughout your product as an Integer Pointer Handle. You have all the other structures documented, why not this very important one? I figured it must be a common structure in NDIS, but after some research, I’m finding that driver developers start adding their custom fields to it. What is the WinpkFilter structure associated with individual Adapter handles, i.e “_ETH_REQUEST.hAdapterHandle” ?
This is internal WinpkFilter structure and it is not accessible from user mode (it is allocated from kernel memory).Thats why it is opaque.
- You must be logged in to reply to this topic.