Hi!

I want to develop a TCP/IP filter. The requisites are:

- I don't need to view/change raw or ethernet packets
- I need to reject incoming/outgoing connections based on IP/port
- I need to deal with RAS.
- It would be good if I could modify data, but I don't need it now.

I have been reading lot of stuff about the pros/cons of NDIS IM driver
and TDI filter drivers. That's my conclusion, please correct me if my
assumptions are wrong:

- NDIS IM will filter interfaces/adapters. So, I'll need to attach to
all adapters, and monitor new adapters (RAS?). I'll also need to deal
with packet data and raw IP.
- To develop a NDIS IM, common kernel development skills and layered
driver knowledge is not enough, since NDIS use other
functions/interfaces. But, there's a sample in DDK and some pages about
how to deal with RAS adapters.
- A TDI filter is a common layered (legacy) driver, like File System
Filters. And hooking TCP and UDP device objects I'll hook all TCP/IP
traffic. If I know how to attach to a device object and how to deal with
IRPs I'll not have (big) problems.

What's the best option, considering I have NT FileSystem development
background? I think what I need is a low level LSP, not a packet analyzer.

I hope I made my self clear.


Regards,


Strauss

Re: NDIS IM driver vs TDI filter by Brian

Brian
Fri Feb 06 15:30:34 CST 2004

"Strauss" <strauss@microsoft.com> wrote in message
news:eKX9cGN7DHA.3648@TK2MSFTNGP11.phx.gbl...
> Hi!
>
> I want to develop a TCP/IP filter. The requisites are:
>
> - I don't need to view/change raw or ethernet packets
> - I need to reject incoming/outgoing connections based on IP/port
> - I need to deal with RAS.
> - It would be good if I could modify data, but I don't need it now.
>
> I have been reading lot of stuff about the pros/cons of NDIS IM driver
> and TDI filter drivers. That's my conclusion, please correct me if my
> assumptions are wrong:
>
> - NDIS IM will filter interfaces/adapters. So, I'll need to attach to
> all adapters, and monitor new adapters (RAS?). I'll also need to deal
> with packet data and raw IP.

Intercepting RAS over modem is EXTREMELY difficult in an intermediate driver.
I've done it, and I don't wish it on anyone else. If you don't need to worry
about modem, then an intermediate is probably OK

> - To develop a NDIS IM, common kernel development skills and layered
> driver knowledge is not enough, since NDIS use other
> functions/interfaces. But, there's a sample in DDK and some pages about
> how to deal with RAS adapters.

True. You need to understand the NDIS upper-edge (miniport edge) and the NDIS
lower-edge (protocol edge). Just about everything you know about driver
development - with the exception of debugging - won't be useful when developing
an NDIS driver

> - A TDI filter is a common layered (legacy) driver, like File System
> Filters. And hooking TCP and UDP device objects I'll hook all TCP/IP
> traffic. If I know how to attach to a device object and how to deal with
> IRPs I'll not have (big) problems.

If you sit on top of TCP, then filtering the connection is a little harder.
Also, there are some big issues with layering on top of TCP, specifically
because NETBEUI/NETBIOS is broken in the way it assumes that there isn't any
layers on top of TCP. The trick is to get attached before NETBIOS does. You
also have to make sure that nothing else is going on in the system when you do
your attachment - a difficult thing to do.

>
> What's the best option, considering I have NT FileSystem development
> background? I think what I need is a low level LSP, not a packet analyzer.

That depends upon what type of RAS filtering you have to do. If you don't have
to worry about RAS over WAN things (modem) then an intermediate driver will
probably be OK.

> I hope I made my self clear.

Clear enough.

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS



NDIS IM driver vs TDI filter by Steve

Steve
Fri Feb 06 17:04:57 CST 2004

Strauss,

You might want to take a look at our DNE product
(http://www.deterministicnetworks.com/Products/dne.asp).
It is an intermediate driver framework that lets you
develop plugin drivers. These plugins can set filters to
see selected (or all) incoming or outgoing packets from
any protocol stack or device driver, including WAN
interfaces through NDIS WAN. Our cusotmers (and we
internally) have used DNE to devleop firewalls, IPSEC
clients, measurement probes, NAT, proxies, load
balancers, QoS, secure multicast, transparent
bridges, 'sniffers', and much more.

It runs cross platform on all Windows systems (95, 98,
ME, NT, 2K, XP, W2K3, as well as CE.net, PocketPC 2003,
Linux, Solaris, etc) and provides a consistent API (via
IOCTL or packet insertion/capture) to user space. A
plugin written for one system will run on all others (a
recompile is necessary between families e.g. between
Windows and Linux). Also, your plugin runs under our
digital signature so you don't have to go through the
WHQL process for your IM.

It comes with virtual LAN (with DHCP spoofing) and WAN
adapters to facilitate things like tunneling and device
spoofing. If you have specific RAS issues, let me know
the detail and I may have some suggestions. As Brian
points out, building a WAN miniport shim is non-trivial,
but depending on what you need to do, we may have some
suggestions.

If monitoring is all you need, depending on the level of
detail, I suspect DNE with a simple plugin (possibly one
we already have in our other products) may be sufficient.


Steve
>-----Original Message-----
>Hi!
>
> I want to develop a TCP/IP filter. The requisites
are:
>
> - I don't need to view/change raw or ethernet
packets
> - I need to reject incoming/outgoing connections
based on IP/port
> - I need to deal with RAS.
> - It would be good if I could modify data, but I
don't need it now.
>
> I have been reading lot of stuff about the
pros/cons of NDIS IM driver
>and TDI filter drivers. That's my conclusion, please
correct me if my
>assumptions are wrong:
>
> - NDIS IM will filter interfaces/adapters. So,
I'll need to attach to
>all adapters, and monitor new adapters (RAS?). I'll also
need to deal
>with packet data and raw IP.
> - To develop a NDIS IM, common kernel development
skills and layered
>driver knowledge is not enough, since NDIS use other
>functions/interfaces. But, there's a sample in DDK and
some pages about
>how to deal with RAS adapters.
> - A TDI filter is a common layered (legacy)
driver, like File System
>Filters. And hooking TCP and UDP device objects I'll
hook all TCP/IP
>traffic. If I know how to attach to a device object and
how to deal with
>IRPs I'll not have (big) problems.
>
> What's the best option, considering I have NT
FileSystem development
>background? I think what I need is a low level LSP, not
a packet analyzer.
>
> I hope I made my self clear.
>
>
>Regards,
>
>
>Strauss
>.
>

Re: NDIS IM driver vs TDI filter by Strauss

Strauss
Sun Feb 08 19:09:54 CST 2004

Brian:

Considering:

- Intercepting RAS over modem is EXTREMELY difficult (and I need
this). Intercepting the protocol, I'll see the traffic from all adapters.
- To develop a NDIS IM I need to study NDIS (not too hard, but... :-))
- In NDIS I will deal with packets, and I don't want to go so low-level
- I know how to replace an IRP buffer, deal with MDLs, etc.

Isn't TDI filter the better option? In the beginning, I'll need only to
reject connections based on the destination address, so I'll need to
hook the connection IRP only


Thank you in advance,


Strauss
>>I want to develop a TCP/IP filter. The requisites are:
>>
>>- I don't need to view/change raw or ethernet packets
>>- I need to reject incoming/outgoing connections based on IP/port
>>- I need to deal with RAS.
>>- It would be good if I could modify data, but I don't need it now.
>>
>>I have been reading lot of stuff about the pros/cons of NDIS IM driver
>>and TDI filter drivers. That's my conclusion, please correct me if my
>>assumptions are wrong:
>>
>>- NDIS IM will filter interfaces/adapters. So, I'll need to attach to
>>all adapters, and monitor new adapters (RAS?). I'll also need to deal
>>with packet data and raw IP.
>
>
> Intercepting RAS over modem is EXTREMELY difficult in an intermediate driver.
> I've done it, and I don't wish it on anyone else. If you don't need to worry
> about modem, then an intermediate is probably OK
>
>
>>- To develop a NDIS IM, common kernel development skills and layered
>>driver knowledge is not enough, since NDIS use other
>>functions/interfaces. But, there's a sample in DDK and some pages about
>>how to deal with RAS adapters.
>
>
> True. You need to understand the NDIS upper-edge (miniport edge) and the NDIS
> lower-edge (protocol edge). Just about everything you know about driver
> development - with the exception of debugging - won't be useful when developing
> an NDIS driver
>
>
>>- A TDI filter is a common layered (legacy) driver, like File System
>>Filters. And hooking TCP and UDP device objects I'll hook all TCP/IP
>>traffic. If I know how to attach to a device object and how to deal with
>>IRPs I'll not have (big) problems.
>
>
> If you sit on top of TCP, then filtering the connection is a little harder.
> Also, there are some big issues with layering on top of TCP, specifically
> because NETBEUI/NETBIOS is broken in the way it assumes that there isn't any
> layers on top of TCP. The trick is to get attached before NETBIOS does. You
> also have to make sure that nothing else is going on in the system when you do
> your attachment - a difficult thing to do.
>
>
>>What's the best option, considering I have NT FileSystem development
>>background? I think what I need is a low level LSP, not a packet analyzer.
>
>
> That depends upon what type of RAS filtering you have to do. If you don't have
> to worry about RAS over WAN things (modem) then an intermediate driver will
> probably be OK.
>
>
>>I hope I made my self clear.
>
>
> Clear enough.
>
> -Brian
>
> Brian Catlin, Sannas Consulting 310-944-9492
> Windows Network, Video, WDM Device Driver Training & Consulting
> See WWW.AZIUS.COM.bad for courses and scheduling
> REMOVE .BAD FROM EMAIL AND WEB ADDRESS
>
>

Re: NDIS IM driver vs TDI filter by Strauss

Strauss
Sun Feb 08 19:10:53 CST 2004


Thanks, but since it's a personal project, I don't have budget to
this... :-)

Steve Jackowski wrote:
> Strauss,
>
> You might want to take a look at our DNE product
> (http://www.deterministicnetworks.com/Products/dne.asp).
> It is an intermediate driver framework that lets you
> develop plugin drivers. These plugins can set filters to
> see selected (or all) incoming or outgoing packets from
> any protocol stack or device driver, including WAN
> interfaces through NDIS WAN. Our cusotmers (and we
> internally) have used DNE to devleop firewalls, IPSEC
> clients, measurement probes, NAT, proxies, load
> balancers, QoS, secure multicast, transparent
> bridges, 'sniffers', and much more.
>
> It runs cross platform on all Windows systems (95, 98,
> ME, NT, 2K, XP, W2K3, as well as CE.net, PocketPC 2003,
> Linux, Solaris, etc) and provides a consistent API (via
> IOCTL or packet insertion/capture) to user space. A
> plugin written for one system will run on all others (a
> recompile is necessary between families e.g. between
> Windows and Linux). Also, your plugin runs under our
> digital signature so you don't have to go through the
> WHQL process for your IM.
>
> It comes with virtual LAN (with DHCP spoofing) and WAN
> adapters to facilitate things like tunneling and device
> spoofing. If you have specific RAS issues, let me know
> the detail and I may have some suggestions. As Brian
> points out, building a WAN miniport shim is non-trivial,
> but depending on what you need to do, we may have some
> suggestions.
>
> If monitoring is all you need, depending on the level of
> detail, I suspect DNE with a simple plugin (possibly one
> we already have in our other products) may be sufficient.
>
>
> Steve
>
>>-----Original Message-----
>>Hi!
>>
>> I want to develop a TCP/IP filter. The requisites
>
> are:
>
>>
>> - I don't need to view/change raw or ethernet
>
> packets
>
>> - I need to reject incoming/outgoing connections
>
> based on IP/port
>
>> - I need to deal with RAS.
>> - It would be good if I could modify data, but I
>
> don't need it now.
>
>>
>> I have been reading lot of stuff about the
>
> pros/cons of NDIS IM driver
>
>>and TDI filter drivers. That's my conclusion, please
>
> correct me if my
>
>>assumptions are wrong:
>>
>> - NDIS IM will filter interfaces/adapters. So,
>
> I'll need to attach to
>
>>all adapters, and monitor new adapters (RAS?). I'll also
>
> need to deal
>
>>with packet data and raw IP.
>> - To develop a NDIS IM, common kernel development
>
> skills and layered
>
>>driver knowledge is not enough, since NDIS use other
>>functions/interfaces. But, there's a sample in DDK and
>
> some pages about
>
>>how to deal with RAS adapters.
>> - A TDI filter is a common layered (legacy)
>
> driver, like File System
>
>>Filters. And hooking TCP and UDP device objects I'll
>
> hook all TCP/IP
>
>>traffic. If I know how to attach to a device object and
>
> how to deal with
>
>>IRPs I'll not have (big) problems.
>>
>> What's the best option, considering I have NT
>
> FileSystem development
>
>>background? I think what I need is a low level LSP, not
>
> a packet analyzer.
>
>> I hope I made my self clear.
>>
>>
>>Regards,
>>
>>
>>Strauss
>>.
>>

Re: NDIS IM driver vs TDI filter by Maxim

Maxim
Sun Feb 08 18:40:31 CST 2004

> Isn't TDI filter the better option? In the beginning, I'll need only to

No. TDI is not simpler then NDIS and worse documented then NDIS, also there is
no 100% reliable TDI filter samples, and there are such samples (from MS) for
NDIS IMs.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Re: NDIS IM driver vs TDI filter by Brian

Brian
Sun Feb 08 21:09:00 CST 2004

"Strauss" <strauss@microsoft.com> wrote in message
news:%23XBnJFq7DHA.2656@TK2MSFTNGP11.phx.gbl...
> Brian:
>
> Considering:
>
> - Intercepting RAS over modem is EXTREMELY difficult (and I need
> this). Intercepting the protocol, I'll see the traffic from all adapters.
> - To develop a NDIS IM I need to study NDIS (not too hard, but... :-))
> - In NDIS I will deal with packets, and I don't want to go so low-level
> - I know how to replace an IRP buffer, deal with MDLs, etc.
>
> Isn't TDI filter the better option? In the beginning, I'll need only to
> reject connections based on the destination address, so I'll need to
> hook the connection IRP only

Yes, that is all true - as far as it goes. However, the TDI interface is not
well documented, and I suspect that you will have a steep learning curve. On
the other hand if you really have to filter over modem, and you don't want to
write your own PPP replacement (this is just one of the things you need to do to
write an IM over RAS-modem), then TDI would be your only other option.

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

>
> Thank you in advance,
>
>
> Strauss
> >>I want to develop a TCP/IP filter. The requisites are:
> >>
> >>- I don't need to view/change raw or ethernet packets
> >>- I need to reject incoming/outgoing connections based on IP/port
> >>- I need to deal with RAS.
> >>- It would be good if I could modify data, but I don't need it now.
> >>
> >>I have been reading lot of stuff about the pros/cons of NDIS IM driver
> >>and TDI filter drivers. That's my conclusion, please correct me if my
> >>assumptions are wrong:
> >>
> >>- NDIS IM will filter interfaces/adapters. So, I'll need to attach to
> >>all adapters, and monitor new adapters (RAS?). I'll also need to deal
> >>with packet data and raw IP.
> >
> >
> > Intercepting RAS over modem is EXTREMELY difficult in an intermediate
driver.
> > I've done it, and I don't wish it on anyone else. If you don't need to
worry
> > about modem, then an intermediate is probably OK
> >
> >
> >>- To develop a NDIS IM, common kernel development skills and layered
> >>driver knowledge is not enough, since NDIS use other
> >>functions/interfaces. But, there's a sample in DDK and some pages about
> >>how to deal with RAS adapters.
> >
> >
> > True. You need to understand the NDIS upper-edge (miniport edge) and the
NDIS
> > lower-edge (protocol edge). Just about everything you know about driver
> > development - with the exception of debugging - won't be useful when
developing
> > an NDIS driver
> >
> >
> >>- A TDI filter is a common layered (legacy) driver, like File System
> >>Filters. And hooking TCP and UDP device objects I'll hook all TCP/IP
> >>traffic. If I know how to attach to a device object and how to deal with
> >>IRPs I'll not have (big) problems.
> >
> >
> > If you sit on top of TCP, then filtering the connection is a little harder.
> > Also, there are some big issues with layering on top of TCP, specifically
> > because NETBEUI/NETBIOS is broken in the way it assumes that there isn't any
> > layers on top of TCP. The trick is to get attached before NETBIOS does.
You
> > also have to make sure that nothing else is going on in the system when you
do
> > your attachment - a difficult thing to do.
> >
> >
> >>What's the best option, considering I have NT FileSystem development
> >>background? I think what I need is a low level LSP, not a packet analyzer.
> >
> >
> > That depends upon what type of RAS filtering you have to do. If you don't
have
> > to worry about RAS over WAN things (modem) then an intermediate driver will
> > probably be OK.
> >
> >
> >>I hope I made my self clear.
> >
> >
> > Clear enough.
> >
> > -Brian
> >
> > Brian Catlin, Sannas Consulting 310-944-9492
> > Windows Network, Video, WDM Device Driver Training & Consulting
> > See WWW.AZIUS.COM.bad for courses and scheduling
> > REMOVE .BAD FROM EMAIL AND WEB ADDRESS
> >
> >



Re: NDIS IM driver vs TDI filter by Maxim

Maxim
Sun Feb 08 22:28:08 CST 2004

> write your own PPP replacement (this is just one of the things you need to do
to
> write an IM over RAS-modem), then TDI would be your only other option.

Why not filter between NDISWAN below us and WANARP above us?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Re: NDIS IM driver vs TDI filter by Alex

Alex
Sun Feb 08 22:32:49 CST 2004


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23fZENUq7DHA.2524@TK2MSFTNGP11.phx.gbl...
> > Isn't TDI filter the better option? In the beginning, I'll need only to
>
> No. TDI is not simpler then NDIS and worse documented then NDIS, also
there is
> no 100% reliable TDI filter samples, and there are such samples (from MS)
for
> NDIS IMs.
>

I'm not seing TDI is better (bucause I don't know), but, what are the
problems with a TDI filter?


> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>



Re: NDIS IM driver vs TDI filter by Brian

Brian
Mon Feb 09 01:02:43 CST 2004

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eAyWYTs7DHA.452@TK2MSFTNGP11.phx.gbl...
> > write your own PPP replacement (this is just one of the things you need to
do
> to
> > write an IM over RAS-modem), then TDI would be your only other option.
>
> Why not filter between NDISWAN below us and WANARP above us?

Because the NDISWAN code passes some data via direct call between modules,
rather than using NDIS, which would allow filtering

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS



Re: NDIS IM driver vs TDI filter by Brian

Brian
Mon Feb 09 01:06:07 CST 2004

"Alex" <AlX@a> wrote in message news:en%23fJXs7DHA.2480@TK2MSFTNGP10.phx.gbl...
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:%23fZENUq7DHA.2524@TK2MSFTNGP11.phx.gbl...
> > > Isn't TDI filter the better option? In the beginning, I'll need only to
> >
> > No. TDI is not simpler then NDIS and worse documented then NDIS, also
> there is
> > no 100% reliable TDI filter samples, and there are such samples (from MS)
> for
> > NDIS IMs.
> >
>
> I'm not seing TDI is better (bucause I don't know), but, what are the
> problems with a TDI filter?

A TDI filter conceptually sits on top of TCP. Unfortunately, you can't just
layer your device object on top because the WINS client (NETBEUI/NETBIOS)
doesn't take that into account, which will cause problems. Therefore, you need
to hook TCP's major function table entry points before any other driver tries to
communicate with TCP, and you must do so in a manner that you *know* no other
code in the system is doing anything with TCP or any of its data structures

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS



Re: NDIS IM driver vs TDI filter by Maxim

Maxim
Mon Feb 09 17:58:19 CST 2004

> Because the NDISWAN code passes some data via direct call between modules,
> rather than using NDIS, which would allow filtering

So, NDISWAN does some direct calls to WANARP which cannot be filtered?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Re: NDIS IM driver vs TDI filter by Brian

Brian
Mon Feb 09 22:38:25 CST 2004

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:O5sMRh27DHA.632@TK2MSFTNGP12.phx.gbl...
> > Because the NDISWAN code passes some data via direct call between modules,
> > rather than using NDIS, which would allow filtering
>
> So, NDISWAN does some direct calls to WANARP which cannot be filtered?

Yep

-Brian