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: Additional TPC/IP stack

RE: Additional TPC/IP stack

Scott Wiegel (slwiegelcisco.com)
Sat, 8 Nov 1997 14:05:17 -0600

Warning: This may be construed as one person's support of a particular
product. I am a primary contributor (technically at least) to the
Centri Firewall product.

As one of the primary architects of the Centri Firewall, let me add a
little bit to this discussion.

> >An NT based firewall I've been reading about is marketted as using an
> >additional TCP/IP stack, which performs additional checking before
> >transerring the packets to the native NT TCP/IP stack. (The firewall
> in
> >question is Cisco's Centri) My questions are:
> > Do you feel that such additional checking in an ad hoc IP stack
> is
> >valuable?
>
> The stack implemented in the Centri product is NOT an ad hoc IP
> implementation. It is an IP implementation that was developed with
> security being the first and foremost thought on everyone's mind. If
> you simply implement a protocol stack in accordance with available
> specifications and not much security knowledge, then all advantages of
> a dual stack architecture are truly lost.
>
> In general, I believe that error checking can never be a bad
> thing. One of the reasons that software has so many security
> problems is because there is an insufficiency of "sanity check"
> interlocks between layers of software. There's too much trust.
> So, it's probably not a bad idea to have different implementations
> that effectively check eachother over for bugs or loose
> interpretations
> of specifications.
>
> The TCP, IP, and UPD modules that have been implemented for the Centri
> firewall were written with one primary goal: To ensure that any and
> all known problems with these specifications were handled in some
> fashion. When you have your own stack (instead of blindly relying on
> someone elses), the information that you can gather and the additional
> security checks that can be implemented allows a level of confidence
> that will never be gained from utilizing some one elses
> implementation.
>
> Most security experts also agree upon a minimalist approach. This
> approach basically states that the software in question does what it
> is supposed to do and nothing else (my loose interpretation). Many
> vendor provided stacks are also responsible for performing additional
> non-security related processing. As such, they tend to grow well
> beyond their original purpose. This slow growth over time can make
> performing any type of security analysis very, very difficult. And
> when a new release arrives every other month...
>
> > What kind of additional checks would make sense?
>
> Mostly, in an IP stack, I'd expect you'd be looking for large
> or corrupt or fragmented or tiny or otherwise weird packets.
> I suppose you might also look at sequencing issues, and
> so forth -- that's about all that you have available to you at
> the IP level, unless you start reassembling all the traffic
> and looking into the data streams (that's a hard problem!).
>
> This is a very accurate list of things that you would look for. Many
> of the problems in modern day TCP/IP stacks can be attributed to poor
> handling (or sometimes correct/accepted handling) of bizarre cases.
>
> For modern firewalls, the information present at the IP, TCP, and UDP
> layers is not sufficient, IMO, to enforce desirable security policies
> for a large number of end-users. In addition, many end-users want
> firewalls that can run on smaller hardware footprints. This was one
> of the driving forces behind the original architectural decision of
> the Centri design team to re-assemble packets (IP and TCP reassembly)
> and allowing the Centri security kernel module the ability to scan all
> application data that passes through the system (without a requirement
> to traverse the Kernel/User Space boundary).
>
> In other words it makes sense but I'm not sure there's a huge
> "bang for the buck" in doing it -- the bulk of the interesting
> holes that are going to let someone punch through a firewall
> are in application software BEHIND the firewall -- which means
> that looking through the stack is less interesting than looking
> at the application stream.
>
> But there is a huge "bang for the buck" if, in addition to these
> checks, you also check the most common application flaws and security
> weaknesses with knowledge (or state, or whatever the term du jour is)
> gained from the protocol stack implementation (and not just the data
> available via the BSD ioctl or Winsock interface).
>
> > Is this a valid/reasonable approach or is it just hype?
>
> I don't know if I'd dismiss it entirely as hype. But I don't know if
> I'd say it adds dramatically to the security of the system in
> question.
> It's also quite possible that the vendor in question chose to go
> that route because of problems (performance/quality/interface)
> with the existing IP stack. I'm cheating here because I already
> know the poster was referring to a particular NT based product
> and I know the guys who wrote it -- a lot of the decision to
> replace the stack was based on early experience with NT's
> IP stack.
>
> Correct as usual. Although two of the other primary driving forces
> were performance and security. We wanted the higher levels of
> security that only an application layer gateway can offer with
> performance metrics similar to a packet filter.
>
> It would be very difficult to state definitively that any of these
> three criteria was the primary driving force behind the architectural
> and design decisions that were made with the Centri Product. It was
> really the combination of all these factors that lead to most of the
> arcitectural/design decisions.
>
> Scott L. Wiegel
> Director, Software Engineering
> Cisco Systems, Inc.
> 107 S. State Street
> Monticello, IL 61856
> 217-762-2375
>

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