Re: New firewall paradigms, anyone ?

["Marcus J. Ranum" <mjr () nfr net>]

> Hmmm, how about a neural net firewall ?

I've given that kind of idea a lot of thought, and even went so
far about 3 years ago, as to to dig up all my books on parallel
distributed processing and try to see if NN would make sense
for security. I wasn't encouraged by the results. :(

> you plug it in
> and run it though all the types of data flows it should expect to see and
> allow through.  This should allow it to build up a pretty good knowledge
> base, so that when it sees something out of the ordinary, it flags it and/or
> drops it.



> I'm not sure how much real teaching would be involved or weighting of strange
> things would help.  For example, if it has looked at lots of http headers,
> it'll know that they usually don't have any IP header options or urgent TCP
> data, so ones which do are "out of the ordinary".  Conversely, if you were
> running something like the old multicast distribution which used source
> routing, it would have seen lots of packets with source routing options
> in place and but expect them to match its multicast model.

There are a few problems with this idea. I'm not sure if they are
killers but they're tough.

The first question to answer is whether network traffic is, in fact,
simple and predictable. We don't know that. (That's one of the
things The Guys and I are researching) I'd guess it is.

The second question is whether attacks are *sufficiently* *different*
from normal traffic that they'd do the right thing. If all you were looking
at was packets (per your examples above) you'd not detect sendmail
bugs being triggered. If you go up into the application stream, then
you have a further problem of defining whether or not application
traffic is simple and predictable. (That's one of the things The Guys
and I are researching)  I'd guess it isn't.

Another interesting question is what types of things to instrument.
When Mikey wrote the TCP reassembly engine for NFR, he
discovered all kinds of things to consider looking at and making
accessible to the filter rules -- things we'd never thought of
before. Do you want to know about packets that have come more
than 2 standard deviations outside of the normal inter-packet
arrival time for a connection? What about packets that are out
of sequence? Or packets that are out of sequence by more than
2 sequence numbers? Which is worse - closely out of sequence
packets or wildly out of sequence packets? My guess is that
closely out of sequence packets are worse but they are also
closer to a "normal error"

Defining a "normal error" versus an "abnormal error" is going to
be A Big Trick. Of course, I believe these days that "errors iz errors"
and we need to merge network management error detection with
security error detection. What's interesting is that lots of people
don't even know what an error is anymore. Things break in all kinds
of weird ways under load and then there's all the johnny-come-lately
IP implementations, which variously drool, cripple, and mutilate
packets, retry timeouts, and session shutdown. Start to add in the
application layer and it gets still uglier. Our NN firewall would have
to "learn" about PointCast... Over HTTP...

The intrusion detection researchers have gone down some of
these routes and my overall impression is that their efforts have
not been highly successful. An obvious proof is the large amount
of hacking activity that continues to take place.

> and on I could go, just yapping about more stuff on how it would work with
> a neural net.  The key part is the "training" but then, how do you add a
> new protocol ?  Send it back to be retrained ?  Costly, but how effective ?

Training a neural net to recognize a new protocol has *GOT* to
be cheaper than coding a firewall proxy for a new protocol!! Based
on my experience, anyhow... :)

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr