Forum Replies Created
-
Posts
-
Since you are using VPN to connect the Internet (VPN link usually have smaller MTU than LAN link) and small packets (ICMP echo/ICMP echo reply) are allowed to pass then I would suspect some problems with Path MTU Discovery.
Some information about Path MTU Discovery can be found here http://www.netheaven.com/pmtu.html
I would try to set smaller MTU on the client system to check this idea by altering (setting to 1492 or even less) the following registry key in the system registry (requires reboot after modification):
// This parameter specifies the Maximum Transmission Unit (MTU) for a network interface.
// By optimizing the MTU setting you can gain substantial network performance increases,
// especially when using dial-up modem connections.
// MTU stands for Maximum Transmission Unit and in basic terms, it defines the maximum
// size of a packet that can be transferred in one frame over a network.
// Recommended Values
// 576 – Dial-up Connections
// 1492 – PPPoE Broadband Connections
// 1500 – Ethernet, DSL and Cable Broadband Connections
// Note: IP datagrams may span multiple packets. Values larger than the default for the
// underlying network will result in the transport using the network default MTU. Values
// smaller than 68 will result in the tranport using an MTU of 68.
// System Key: [HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
// Interfaces[Adapter ID]]
// Name: MTU
// Type: REG_DWORD (DWORD Value)
// Value: Default = 0xffffffff ???
// Note Windows 2000 TCP/IP uses PMTU detection by default and queries the NIC driver to find
// out what local MTU is supported. Altering the MTU parameter is generally not necessary and
// may result in reduced performance. See the PMTU detection discussion in the TCP section
// of this document for more details.[Adapter ID] has a form of GUID, an example path to my LAN NIC registry key is the following HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersInterfaces{1E79EC84-A8E9-4A2F-BB11-0FF68F46E5A9}
Hmmm… this should work, ndis.h defines the NdisMSendComplete() macro and it uses that member… strange… What do you think? I could also hook a SendCompleteHandler inside NDIS_OPEN_BLOCK, but, that would not be the earliest function… What do you think?
If miniport driver was compiled with BINARY_COMPATIBLE flag set (allows having same binary for Windows 9x and NT) then NdisMSendComplete called as NDIS export not as macro. May be this is the reason…
If every firewall were written as NetFirewall is, it would be possible to create a trojan horse using Winpcap and there would be no way to stop it.
Well, NeT Firewall is created to protect system from the external intrusion, not from the internal one. And trust me, it is not great problem to create a trojan which will bypass any firewall available on the market (such trojan still can be detected by analyzing infected system’s network traffic from another system). It requires strong skills in kernel development and not fast and easy to implement but still… It is 5 minutes to rebuild NeT Firewall to intercept winpcap, but it does not really makes sense. If you want to avoid installing trojan protocol just don’t work under admin account (without having admin rights non of the trojans can install a driver). In general don’t expect that if you install a firewall you can do anything and you are safe.
There is a separate set of products, so called kernel IDS targetted to protect your system from trojan software and system exploits. Firewall primary target is protecting your local network stack from external attacks and thats it. Implementing partial kernel IDS in the firewalls (like ZoneAlarm, an example) give you rather illusion of safety than real safety.
The issue comes up when I copy the packet and submit the newly created packet descriptor. _ndisMSendCompleteX@12 crashes trying to access something inside the packet, just after referencing _ndisPacketStackSize.
Well, as far as I can see without going deep into the problem the only difference is that original packet was preprocessed by NDIS send handler but your packet was not. You can analyze what fields were exactly referenced and fix it. I would not recommend this because internal NDIS packet processing may change from OS and SP.
Another way is intercepting NdisMSendComplete and checking if it is your packet descriptor passed to it and if yes then releasing your packet resource without passing it to NDIS. Also don’t forget to release packet descriptors for the original packets.
NeT Firewall puts its packet filter between TCP/IP protocol driver and network interfaces. Winpcap installs its own protocol driver which works at the same level as TCP/IP (in parallel) and not intercepted by NeT Firewall. Basically, if you expect high security you should avoid having any other protocls (like winpcap) installed on the system. Primary purpose of NeT Firewall is protecting TCP/IP stack (not winpcap or any other custom protocol).
In general it is possible to intercept other protocols (like winpcap, ndisuio and etc..) in addition to TCP/IP protocol however this approach has some serious disadvantages (may break third-party NDIS intermediate drivers functionality, custom protocols and etc.) and since NeT Firewall is oriented on users who know what happens on their systems it is implemented on the current way.
first of all I excuse for I’m late on answering you, I was busy with university: my porfessor Federico Simonetti of University of Milan says hello to you
My warm regards to Federico, I hope he is doing well 🙂
What I’d like to ask you is: is there any way to make NetFW look at the PORT command in the control connection on 21 TCP port to automatically open the port the server wants to use to transfer data? As an example, Netfilter/IpTables can do it, and other commercial firewalls as well.
Yes this is possible but, heh, not implemented yet and the only known solution is opening port 20 for everyone. 😕 Dynamic rules (temporary rules created under certain conditions) are planned to be implemented, but it still needs time. In the meantime only Stealth 3rd level takes into account FTP protocol realization details so outgoing FTP can work in active mode.
Please send your registration e-mail (registrtion name or any other information we could use) and approximate date of purchase to [email protected] so we could identify your order.
P.S. Some FTP relative information http://slacksite.com/other/ftp.html
With the FW on 3rd level security if I permit 21/TCP out and I block all the other outgoing traffic passive ftp doesn’t work.
FTP active mode uses two TCP sessions, one on server port 21 is a control channel and another data channel on server port 20. Control channel is established by client and data channel is established by server as a response on PORT command.
In passive mode both control and data channels are established by client. Data channel uses arbitrary ports >1024 on both server and client sides. In you case blocking all outgoig connections except port 21 does not allow client to establish data channel and FTP in passive mode does not work.
The new version of NeT Firewall 2.3.2.3 has been released. We have updated the interpretation of IN/OUT keywords for TCP protocol, now it is applied to incoming/ougoing connections instead of incoming/outgoing packets. For other protocols IN/OUT interpretation remains the same. This should help to avoid missunderstandings in the future.
Basically using atexit() the way you did is not correct, you should pass a static function to atexit() instead of C++ class method. Also, since you are making the windows service you can release interfaces when your service process is stopped instead of using atexit().
From the design point of view I would create a C++ classe to wrap each interface and manipulated adapter thru this class ( ReleaseInterface functionality could be placed into the class destructor). Some more advanced WinpkFilter code can be downloaded from this page http://www.ntkernel.com/w&p.php?id=31 once you are a registered customer.
Well, you are right, but this is not about statefull inspection but the way the rules were originally implemented. IN means incoming packets, OUT means outgoing packets (in current implementation specifying only IN or only OUT for TCP protocol is senseless) and it is not exactly the same as IPFW rules where IN means incoming connection, OUT means outgoing connection for TCP. I agree that this may confuse a bit and probably it makes sense to change this behavoiur in order to avoid missunderstandings. Thanks for pointing this.
The rule you have created allows any system connect your port (from any port) 80 and connecting any your local port from port 80 what really breaks any security. Basically if you want to allow any kind of outgoing connections you are supposed to use on the the Stealth Security levels and create rules to drop undesired outgoing connections and may be some rules to open local ports if you also work as server. High Securty level was designed for servers which are supposed not to go outside world but just open some local ports to provide services for their users.
Adapters are bridged at the Etherent level and still have different IP’s if assigned so.
Does this software work like a bridge under XP with only one IP for the 2 connection?
No.
Regarding MTU: As far as I know, windows default MTU for ethernet adapters is 1500. I always attach a 20 bytes key to outgoing UDP packets.
Can I conclude from this that I might have a problem only with packets whose total length is 1480 bytes or more ?Yes, you will have problems with packets which size is equal or close (so you don’t have 20 bytes in reserve) to MTU. There is a special API in WinpkFilter SetMTUDecrement. In your case if maximum size of the attached data is 20 bytes so you should call SetMTUDecrement with 20 as a parameter, please note that this API adds a driver specific value into the registry and requires reboot to take an effect (driver reads this value from the registry during start up).
Can I catch packets that are directed either to 127.0.0.1 or to the local IP ? are those packets passed down the TCP stack or are they redirected by Windows back to the application at higher levels ?
Packets directed to 127.x.x.x or local IP never reach NDIS level and processed internally by TCP/IP. However, these data can be intercepted at the TDI level http://www.ntkernel.com/w&p.php?id=8 and http://www.ntkernel.com/w&p.php?id=24
Just thought to mentioned that I’m using the runtime libraries that are available at the web site (hxxp://www.ntoskrnl.com/downloads/winpkflt_rtx86.zip).
These binaries have no limitations.
Well, first of all I would start this application under debugger and check where it stops (or what is it doing) when network is frozen. Since this is a packet filtering application the network freeze can be easily caused by application hang (some dead lock or endless loop).
Also, I think it is important to mention that you should set MTU decrement if you are attaching additional data to the packets to the maximum size of the attached data. The total size of the ethernet frame should not exceeed 1514 bytes. I can’t see from your code if any length checks are implemented.
