Where is the packet from

[Anonymous]

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

[Vadim Smirnov]

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.

[Anonymous]

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

[Vadim Smirnov]

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.

[Anonymous]

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

[Vadim Smirnov]

@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.

[Anonymous]

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 ??

[Vadim Smirnov]

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.

[Anonymous]

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……

[Anton]

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.

[Anonymous]

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…..

[Vadim Smirnov]

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.

[Author]

Posts