Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 1,006 through 1,020 (of 1,486 total)
  • Author
    Posts
  • in reply to: lhmon.sys and F-Secure antivirus #6497
    Vadim Smirnov
    Keymaster

      We have managed to find a workaround for LHMON problem with F-Secure by hooking TCPIP dispatcher table just before F-Secure driver. The solution is not ideal because any other similar TDI filter may break this balance but this is still better than nothing. The Local Network Monitor was updated on the web site to version 2.2.4.

      in reply to: MySQL cannot start under Net FireWall #6498
      Vadim Smirnov
      Keymaster

        I don’t think that NeT Firewall may affect MySQL start (firewall works on the packet level and does not directly affect socket creation), probably this is something else. If you suspect NeT Firewall try to remove it and see if MySQL starts. Alternatively you can also select to unload rules on the exit in the options and shutdown the console. Or even just put all interfaces to Low Security and remove all rules. This disables any packet filtering.

        However, As I have mentioned NeT Firewall can’t affect MySQL start, it can only block external access to ports used by MySQL.

        in reply to: lhmon.sys and F-Secure antivirus #6495
        Vadim Smirnov
        Keymaster

          F-Secure package contains a driver named fsndis5.sys which is TDI filter + NDIS filter + … in one module. TDI filter part is implemented by patching TCPIP.SYS dispatcher table method. Since this driver is loaded before TCPIP.SYS it applies its patch when it detects the first access attempt to DeviceTcp. However, unlike most filter drivers which patch this table only once, fsndis5.sys checks if anyone patches the TCPIP.SYS dispatcher table after him and re-patches it so that fsndis5.sys is always on the top of the stack. But the re-patching implementation is buggy and this bug reveals if another TDI filter driver based on patching dispatcher table is present. An example, when LNM (Local Network Monitor) driver is loaded it gets the fsndis5.sys installed hooks from the TCPIP.SYS dispatcher table, saves them as original handlers and modifies dispatcher table. So far so good, LNM driver gets the request first, processes it, and then passes to fsndis5.sys which after its own processing passes the request to TCPIP.SYS. However, after short amount of time fsndis5.sys detects that handlers in the TCPIP.SYS dispatcher table have changed and patches this table again BUT it saves LNM driver handlers as original (it already has the correct handlers after previous patch, but for some reason prefers to take the incorrect ones). After this any request directed to DeviceTcp first comes to fsndis5.sys, which after processing passes it to LNM driver, which also after processing passes the request to fsndis5.sys which again calls LNM driver and so on until stack overflow.

          Same crash scenario can be also reproduced with TDIMon (from Mark Russinovich).

          If fsndis5.sys would not take the new modified (LNM driver) handlers from TCPIP.SYS dispatcher table it could just exclude LNM driver from the stack and keep system stable. However, in general the re-patching approach in F-Secure driver is not compatible with any other TDI filter based on patching the dispatcher table.

          in reply to: How to get source IP address in TDI filter driver? #6493
          Vadim Smirnov
          Keymaster

            Once the connection is established you can query the IP it was done from, but NOT before.

            in reply to: How to get source IP address in TDI filter driver? #6491
            Vadim Smirnov
            Keymaster

              TDI_QUERY_INFORMATION allows getting both IP address and port. Refer the structures below in the DDK docs or MSDN.


              typedef struct _TA_ADDRESS {
              USHORT AddressLength;
              USHORT AddressType;
              UCHAR Address[1];
              } TA_ADDRESS, *PTA_ADDRESS;

              typedef struct _TA_ADDRESS_IP {
              LONG TAAddressCount;
              struct _AddrIp {
              USHORT AddressLength;
              USHORT AddressType;
              TDI_ADDRESS_IP Address[1];
              } Address [1];
              } TA_IP_ADDRESS, *PTA_IP_ADDRESS;

              typedef struct _TDI_ADDRESS_IP {
              USHORT sin_port;
              ULONG in_addr;
              UCHAR sin_zero[8];
              } TDI_ADDRESS_IP, *PTDI_ADDRESS_IP;
              in reply to: what’s the time to release new version for winpkfilter #6482
              Vadim Smirnov
              Keymaster

                please,what’is the time for release the new version.

                I admit the 3.0.4 release was delayed several times already. However, this was done for the reason. Actually current 3.0.4 beta is already used by some customers and we are trying to take into the account their comments and suggestions. Once this process is completed (I hope it is already but better wait for the latest test reports) the new version will be available for public.

                If you are a licensed customer you also can participate in WinpkFilter beta.

                in reply to: IPTables Redirect NAT Support #6487
                Vadim Smirnov
                Keymaster

                  Is it possible to get the same functionality (NAT redirect) as IPTables?

                  It is possible to create NAT solution on top of WinpkFilter. An example, Internet Gateway http://www.ntkernel.com/w&p.php?id=31 is a simple NAT implementation based on WinpkFilter library.

                  in reply to: Rules for interface filtering #6486
                  Vadim Smirnov
                  Keymaster

                    TDI нужен только для контроля приложений, так что в TDI фильтре имеет смысл проверять можно ли приложению работать с сетью или нет (в расширенном варианте можно так же проверять на какой адрес приложение хочет создать соединение), а пакетную фильтрацию по IP/интерфейсу лучше организовывать на NDIS’е.

                    in reply to: Shaping Howto #6485
                    Vadim Smirnov
                    Keymaster

                      I believe that storing of packet information in the winpkfilter framework is unlikely as not releasing packet (as in passthru) is not informed back to the framework (like drop indication).

                      You are right, WinpkFilter does not keep any references to the packet passed to you for the processing. In general your approach to making packet queues is ok.

                      in reply to: what’s the time to release new version for winpkfilter #6479
                      Vadim Smirnov
                      Keymaster

                        SendFlagTcpPacketToTcp(Lastpacket,Flag,fromip,toip,from port,toport);

                        It would also need SEQ and ACK. Basically you can write such a function using the existing API completely in user mode.

                        by the way,how to get the IFS HOOK like winpktilter(NDIS HOOK)?

                        Create an IFS filter driver. There is a static IFS filter sample in the IFS kit (or in the latest WDK) names sfilter and dynamic IFS filter driver authored by Mark Russinovich used in Filemon. The source code for the last one was floating over the Internet, not the latest version but still.

                        in reply to: what’s the time to release new version for winpkfilter #6477
                        Vadim Smirnov
                        Keymaster

                          hope more fast~~~~~~

                          It is ready but due to the reasonable amount of changes/extensions still needs more testing.

                          deny ip in the ring0

                          Yes, this is possible in 3.0.4

                          send rst packet by one sub~~~

                          Adding such a specific API would be an overhead because requires knowledge of current connection status (tracking all TCP sessions just to be able to send RST will affect perfomance), it is not a great problem to form RST packet in your code and then send it using WinpkFilter API if you need such functionality.

                          in reply to: Aadapter associated packet queue checkup #6476
                          Vadim Smirnov
                          Keymaster

                            Баг? Или я что-то не понял?

                            Баг – громко сказано, никаких серьезных негативных последствий тут нет. Однако, с точки зрения производительности, ресетить event лучше после вычитывания пакетов из драйвера.

                            ЗЫ Надо будет поправить, чтобы вопросов не возникало…

                            in reply to: Aadapter associated packet queue checkup #6474
                            Vadim Smirnov
                            Keymaster

                              Интересно, как именно происходит проверка состояния очереди?
                              Может есть какой то отдельный поток, который в цикле просматривает состояние очереди, и если она не пуста – сигнализирует в режим юзера?

                              Когда драйвер перехватывает пакет, он его ставит в очередь и выставляет событие сигнализирующее, что очередь не пуста. User-mode поток ожидающий (WaitForSingleObject/WaitForMultipleObjects) на этом событии пробуждается ото сна и читает пакеты из очереди пока они не закончатся, затем ресетит событие и снова ждет на нем. В общем-то, пример passthru показывает как это делается.

                              Альтернатива – polling пакетов без использования событий (пробуем читать пакет, если чтение успешно, то вычитываем все пакеты пока не кончаться, если чтение неуспешно – засыпаем на какое-то время, пример packetsniffer), но на мой взгляд этот метод менее эффективен.

                              in reply to: loopback sniffer (не работает) #6473
                              Vadim Smirnov
                              Keymaster

                                Смотря что понимать под loopback пакетами. В контексте WinpkFilter под loopback пакетами понимаются пакеты, которые были посланы на реальный сетевой интерфейс и затем показаны (вызваны receive обработчики) локальным протоколам. Благодарая этому механизму, в частности, могут работать сетевые снифферы реализованные в форме протоколов, как например winpcap. Без этого механизма winpcap не смог бы увидеть пакеты уходящие в сеть от TCP/IP.

                                Совсем другая история с пакетами отправленными на локальные сетевые интерфейсы (на свой собственный адрес) или на localhost (127.XXX.XXX.XXX). Эти пакеты собсвенно никогда не доходят до NDIS, а обрабатываются внутри TCP/IP стека, так что увидеть их с помощью WinpkFilter не удасться. Они собсвенно и не принимают зачастую привычную форму сетевых пакетов. Однако сами данные перехватить действительно можно анпример при помощи TDI фильтра:

                                http://www.ntkernel.com/w&p.php?id=24
                                http://www.ntkernel.com/w&p.php?id=8

                                in reply to: SPI/DPI #6472
                                Vadim Smirnov
                                Keymaster

                                  But what may happen in case a packet is twisted in a way ? For example wrong packet length or something like that. Can a twisted packet cause BSOD, for example ? (It is rather DPI than SPI I think).

                                  WinpkFilter driver checks validity of buffers supplied by user, but it does not take care about the packet content. So you can send absolutely anything if modules below and above WinpkFilter accept this.

                                Viewing 15 posts - 1,006 through 1,020 (of 1,486 total)