Firewall Wizards mailing list archives
Re: Important Comments re: INtrusion Detection
From: Rick Morrow <rmorrow () delfax net>
Date: Sun, 15 Feb 1998 09:17:04 -0500 (EST)
On Sat, 14 Feb 1998 tqbf () secnet com wrote:
I would disagree, as this conclusion would not take into account the need for a secondary source of information regarding the hosts which are possible targets. There is a strong need for context to be able toBelieve it or not, the proxy solution actually solves quite a number of problems. I spent about 40 minutes yesterday trying to explain to Kurt
[...]
A proxy gateway has the distinct advantage of being a connection endpoint. In the terminology I've been using lately, I'd say that a proxy-sniffer is an ACTIVE (not passive) monitor. Say we have hosts A (the attacker), B
[...] Forgive me if, by unlurking and adding to the thread, I am stepping in well over my head. :) I've noted some interesting trends in this thread, and see some relationships to other topics that have appeared recently. First of all, if we make the IDS an active endpoint for the connection can we, using the classic definition of an IDS, still call it an IDS anymore? Wouldn't it at that point become a firewall with IDS capabilities? Mind you, I'm not saying this is a bad thing, and I certainly wouldn't be so presumptuous as to say that this looks like a step forward in firewall technology. But it does (IMHO) :-). And it would also seem that for the most part some of the list members see it as that as well, although I wouldn't be so presumptuous as to speak for anyone else... One comment was made in a recent message in this thread about the need to preserve a sense of a remote context. Perhaps this _can_ be done with this kind of proxying scheme. One of the things that I usually do on installations, at least in the proofing stage, is to run packet monitors on both the outside and inside of the firewall. With a bit of data reduction and analysis I am able to get a sense of the behaviour of the firewall. What if we used something like this, and extended it slightly to provide our sense of context? We could monitor the packet stream at three points; 1. At the outside of the firewall (the results of which would look much like what a contemporary IDS would obtain), giving us a sense of the raw data reaching the firewall. 2. Somewhere within the TCP/IP stack, at a point during the processing that the packets have completed any modifications in order to pass them up the stack, but before any firewall rules have been applied. 3. On the inside of the firewall, giving us a representation of the resultant packet stream after the rules have been applied. The thing about this is that you get a picture of the data stream at all stages. You can see the early warning signs of an attack from stage 1, get a picture of the data stream after reassembly at stage 2, and finally be able to see what is making it through the firewall in stage 3. Individually each of these monitor points might be of limited value, but if their datum were analyzed in context with each other would that not be able to give us a fairly accurate picture of what is really happening? If a reactive stance is desired then the conclusions from the 3 point analysis could be applied back to the rule-set, in either a positive or negative feedback mode, depending on the preference. I realize that I am talking about adding a lot into what a firewall is expected to do, but if the firewall were designed in a modular sense then it should be relatively easy to add to any firewall the modules neccesary to do the monitoring at the three stages. Designing the analysis module would probably be more difficult, but certainly not impossible. I think that the most difficult module to get right in a scheme like this would be the feedback module. Considering its ability to directly affect the operation of the firewall there would be tremendous potential for catastrophic error. Potential bottle-necking would be another possible problem, but considering the kinds of processing power that can be had cheaply these days a proper design should be able to avoid being a bottleneck. Anyways, this has been my two cents on this topic. Hopefully it has brought up some useful points into the discussion. If not, then back to full lurk mode I go. :-) ----------------------------------------------------------------- Rick Morrow, North Bay, Ontario, Canada rmorrow () delfax net, rmorrow () onlink net PGP Public Key: http://www.delfax.net/~rmorrow/pgp_pub.key
Current thread:
- Important Comments re: INtrusion Detection tqbf (Feb 13)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 14)
- Re: Important Comments re: INtrusion Detection Craig Brozefsky (Feb 14)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 14)
- Re: Important Comments re: INtrusion Detection Craig Brozefsky (Feb 14)
- Re: Important Comments re: INtrusion Detection Marcus J. Ranum (Feb 14)
- Re: Important Comments re: INtrusion Detection Aaron Bawcom (Feb 15)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 16)
- Re: Important Comments re: INtrusion Detection Craig Brozefsky (Feb 14)
- Re: Important Comments re: INtrusion Detection Bret Watson (Feb 14)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 15)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 14)
- Re: Important Comments re: INtrusion Detection Rick Morrow (Feb 15)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 14)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 15)
- Re: Important Comments re: INtrusion Detection Paul M. Cardon (Feb 16)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 16)
- Re: Important Comments re: INtrusion Detection Adam Shostack (Feb 18)
- Re: Important Comments re: INtrusion Detection Paul M. Cardon (Feb 18)
- Re: Important Comments re: INtrusion Detection Paul D. Robertson (Feb 16)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 16)
- Re: Important Comments re: INtrusion Detection Aleph One (Feb 16)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 16)