Where is the packet from

Home Forums Discussions Support Portal Where is the packet from

This topic contains 11 replies, has 3 voices, and was last updated by  Vadim Smirnov 10 years, 11 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #5079

    ulli-um
    Participant

    hi,

    is there a chance to get informations about the process which sents a packet.
    i want to add it to my firewall, because i could open the port for only one process for example.

    thx
    ulli

    #6190

    Vadim Smirnov
    Moderator

    Process context is not available at NDIS (packet level). Alternatively you can build a table for processes< ->open ports and use this table to match packet to processes when processing packet at NDIS level. Such a table can be build an example using TDI filter or LSP.

    #6191

    ulli-um
    Participant

    hi,

    1. I read the description about WinpkFilter again, and I saw that your projekt also supports TDI… how can I use it to get the proccess id…do you have an example

    2. is it possible that one packet by pass the NDIS tunnel? and therefore should I add a TDI Filter to my NDIS firewall ??

    thx
    ulli

    #6192

    Vadim Smirnov
    Moderator

    You can find the TDI filtering solution here http://www.ntkernel.com/w&p.php?id=8

    Packets can’t bypass NDIS layer, but if you want an application context you need something like TDI filter. Most of the desktop firewalls on the marker is a combination of NDIS and TDI/LSP filters.

    #6193

    ulli-um
    Participant

    hi,

    what is the reason for the most desktop firewalls to add a combination of NDIS and TDI ?
    To get the proccess id which is the packet from?? or why?

    thx for the fast answere
    ulli

    #6194

    Vadim Smirnov
    Moderator

    @ulli-um wrote:

    hi,
    what is the reason for the most desktop firewalls to add a combination of NDIS and TDI ?
    To get the proccess id which is the packet from??

    Yes, thats right.

    #6195

    ulli-um
    Participant

    i take a look at your TDI driver, but it can only monitor ip packets or block packets which match a rule….i want to decide it self…if the packet can pass the TDI-System

    is it possible to tunnel packets like your NDIS driver…..
    it is necessary to check if the packet from the right proccess…

    can you help me to find a solution to attach a packet to his process ??

    #6196

    Vadim Smirnov
    Moderator

    i take a look at your TDI driver, but it can only monitor ip packets or block packets which match a rule….i want to decide it self…if the packet can pass the TDI-System

    is it possible to tunnel packets like your NDIS driver…..

    Possible but the driver should be changed for this.

    can you help me to find a solution to attach a packet to his process ??

    Another option is a Layered Service Provider (LSP), you can read more in MSDN.

    #6197

    ulli-um
    Participant

    I want to create a connection table, but I dont understand the messages which came from your tdimon driver.

    what event is necessary to create my connection table?


    Message #=1
    Request origination
    LogInfo.m_ID = 1
    LogInfo.m_EvtType = Create
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 0


    Message #=2
    Request origination
    LogInfo.m_ID = 2
    LogInfo.m_EvtType = Create
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 0


    Message #=3
    Request origination
    LogInfo.m_ID = 3
    LogInfo.m_EvtType = Associate Address
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 4
    00 2B E2 86 .+..

    Message #=4
    Request origination
    LogInfo.m_ID = 4
    LogInfo.m_EvtType = Create
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 0


    Message #=5
    Request origination
    LogInfo.m_ID = 5
    LogInfo.m_EvtType = Associate Address
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 4
    00 2B E2 86 .+..

    Message #=16
    Request completion
    LogInfo.m_ID = 16
    LogInfo.m_EvtType = Incoming Connection
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 127.0.0.1:2299
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 16
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    Message #=17
    Request completion
    LogInfo.m_ID = 17
    LogInfo.m_EvtType = Accept
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 127.0.0.1:2299
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 16
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    Message #=18
    Request origination
    LogInfo.m_ID = 18
    LogInfo.m_EvtType = Incoming Connection
    LogInfo.m_OperationStatus = TDI_MORE_PROCESSING
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 127.0.0.1:2298
    LogInfo.m_RemoteAddress.m_Ip = 127.0.0.1:2299
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 16
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

    Message #=24
    Request completion
    LogInfo.m_ID = 24
    LogInfo.m_EvtType = Close
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 0


    Message #=25
    Request origination
    LogInfo.m_ID = 25
    LogInfo.m_EvtType = Disassociate Address
    LogInfo.m_OperationStatus = TDI_SUCCESS
    LogInfo.m_Protocol = TCP
    LogInfo.m_LocalAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_RemoteAddress.m_Ip = 0.0.0.0:0
    LogInfo.m_szProcessName = thunderbird.exe:2180
    LogInfo.m_DataOffset = 0
    LogInfo.m_DataLength = 4
    00 00 00 00 ....

    what does it mean?

    these messages are the same…but why were messages sent twice??

    can you tell me which event type should me used to add the process, port and address to my connection table?
    and which event should remove the entry in my connection table?

    i hope you can help me……

    #6198

    Anton
    Participant

    These messages are system TDI-level messages wrappers. All messages have TDI_EVENT_TYPE enumeration type and defined in includecommon.h. Message can be reported before it was processed by TCPIP stack (request origination) and after it was processed by TCPIP stack (request completion).

    In your case tdi messages mean:
    Message #=1
    Create Address object on IP-address 120.0.0.1:2298
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=2
    Create connection endpoint
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=3
    Bind connection endpoint to address object
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=4
    Create the second connection endpoint
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=5
    Bind the second connection endpoint to address object
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=16
    The incoming connection request from 127.0.0.1:2299 to 127.0.0.1:2298
    Protocol TCP, process name thunderbird.exe, process id 2180

    Message #=17
    Accept the incoming connection request from 127.0.0.1:2299 to 127.0.0.1:2298
    Protocol TCP, process name thunderbird.exe, process id 2180

    You can use TDI_EVT_CONNECT and TDI_EVT_INCOMING_CONNECTION events to store connection information into the connection table and TDI_EVT_DISCONNECT, TDI_EVT_INCOMING_DISCONNECT to remove it.

    #6199

    ulli-um
    Participant

    Hi,

    now I have two systems one NDIS system to tunnel packets which are allowed and a TDI system which creates a connection/processID table.
    the table is used in the NDIS system to check if the packet is allowed for the process.

    the problem is the NDIS system gets the packets faster than the TDI system….can it be?

    the TDI system catches the following events:
    TDI_EVT_CREATE
    TDI_EVT_CLOSE

    but the NDIS system looks after the port before the tdi system catches the create socket event….

    I saves the connections by localport because the localport can only used by one process…..

    #6200

    Vadim Smirnov
    Moderator

    Basically TDI is above NDIS, but some events logged by TDI filter upon completion, an example in case of sending an outgoing packet TDI filter will pass this packet to NDIS, get the return status and log it after this. So you got packet from NDIS before than from TDI.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.