OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: RE: Firewall comparison in Data Communicat

RE: Firewall comparison in Data Communications

Robert Graham (robert_david_grahamyahoo.com)
Wed, 2 Jun 1999 20:50:00 -0700 (PDT)

Apparently there is some confusion in the statements I've made (caused
by me, I'm afraid).

There are 3 places that you can implement firewall functionality in
WinNT:

1. below the TCP/IP layer as a "filter driver" (between the adapter's
NDIS driver and the TCP/IP stack).

2. above the TCP/IP stack at the TDI layer, like the TDItrace driver
that comes with the resource kit. This would be appropriate for
TCPwrappers style functionality. See
http://www.microsoft.com/DDK/DDKdocs/win98ddk/vxdtdi_42nn.htm

3. the Win2k firewall API, which allows nifty things such as filtering
packets AFTER reassembly. See
http://www.microsoft.com/DDK/DDKdocs/Win2k/firewall_3yax.htm

What I meant to say is that you can implement firewall functionality at
level (1), but it needs the same level of COMPLEXITY as the TCP/IP
stack. On one hand, it doesn't need to worry about sending TCP
retransmits (and maintaining those timers), but on the other hand, it
needs to worry about a number of things at the application layer (i.e.
be able to filter packets to/from port 53 that don't conform to the DNS
specification).

One feature you get from this is that you don't have to follow any spec
(like the host requirements RFC). For example, a firewall filter driver
may discard suspiciously fragmented packets that would otherwise cause
the WinNT TCP/IP stack to crash. Another example is that host MUST pay
attention to ICMP Source Quench, but firewalls MAY discard them. I'm
not quite sure what the RFC-police will say when both are on the same
machine.

In any case, we were talking about "source routing". Firewalls from
Conseal to FW-1 filter out these packets. You can also download sample
code and make your own filter driver. If that's the level at which we
are willing to do things, you can probably patch anything you perceive
as a bug in Microsoft's TCP/IP implementation without getting into
Microsoft's source.

Sorry for phrasing this in a confusing manner. The original point is
something which I think people agree with, even though I may phrase it
in a manner almost anyone would disagree with (and make myself look
stupid in the process).

Rob.

--- Russ <Russ.Cooperrc.on.ca> wrote:
> If you want to make "any/all feature/bugs of the Microsoft stack
> irrelevant", you need to do more than simply replace TCPIP.SYS. You
> need
> to either implement an NDIS Wrapper or replace/provide an NDIS driver
> and tied TCPIP.SYS driver.
>
> Otherwise the NDIS components could accept and forward packets
> destined
> for other protocols (e.g. DLC, NetBEUI, NWLink).
>
> Replacing TCPIP.SYS alone is not enough to make the statement you've
> made. If there is a TDI interface from the replacement TCPIP.SYS,
> then,
> possibly, much of NT's "feature/bugs" might be exploitable. An
> interesting experiment which I haven't seen reported before might be
> the
> use of TDITrace (from the NT Resource Kit) on boxes that "harden" the
> MS
> TCP/IP implementation (either through replacement or otherwise) to
> see
> just what gets passed.
>
> While some changes are expected in Windows 2000, I've still yet to
> hear
> anyone claim that they'll be able to implement either TCPWrappers or
> IPFilter-like functionality on W2K.
>
> Cheers,
> Russ - NTBugtraq Editor
>

_________________________________________________________
Do You Yahoo!?
Get your free yahoo.com address at http://mail.yahoo.com

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:18:59 CDT