PROPOSAL: Modifications to firewall schema

[Francis J. Lacoste]

Thanks Wytze for your comments! Some more notes follows...

On Fri, Jan 11, 2002 at 06:18:05PM +0100, Wytze van der Raay wrote:
> Francis J. Lacoste wrote:
> 
> >Proposal for modifications to the firewall superservice schema
> >==============================================================
> 
> 
> A general remark: although this is called the firewall superservice,
> the type of data gathered/analysed here actually describes IP flows.
> So it is just as applicable to router traffic data (but accounting
> for those is usually done on the device itself, e.g. cisco accounting).
> 
> 
> >After implementing ipchains, iptables and the welf converters, I saw a
> >lot of information which wasn't used and that could be interesting. I
> >propose to add the following fields:
> >
> >- from_host
> >- to_host
> >
> >Used to contains the hostname associated with the IP address. WELF
> >logs can contains that information. (Also I plan on implementating a
> >lr_gethostbyaddr to resolve IPs offline).
> 
> 
> I am definitely looking forward to that one!
> lr_gethostbyaddr would be very useful for several other reports too,
> e.g. the DNS reports.

Indeed. And also for the www superservice.

> 
> One could argue that from_host and to_host are derivable data given
> from_ip and top_ip, but the mappings are far from stable, so it seems
> reasonable to me to include them as primary data fields.

I added in the primary schema because some firewalls will perform the
DNS lookup themselves. (Well, this is what is suggested by the WELF
specification, I haven't seen any that does, but who knows...)

[...]

> 
> 
> How do you intend to handle the "count" field that is found with
> some devices (in particular cisco routers)? Duplicating N DLF lines
> in case the count is N seems rather wasteful -- would it be possible
> to add a "count" field in the DLF (default 1), or does this mess up
> the subsequent processing?

I already suggested as a way to solve the firewall issue to add a count
field (which would default to one for ipchains, ipmon and other).
Joost argued against (and to print N DLF line) which more reflects what
a DLF means -> one event (which should be a packet) = 1 line. 

But, it seems that most firewall products don't agree with that
philosophy. (Even iptables support configuration of not logging all
packets). SonicWall will also logs that a particular packet was seen
many times but log only once (I haven't yet figured how they mark such
event, but that is what ther docs says). 

So, with the addition of WELF and the fact that we already break that
semantic of one packet = one DLF (with the packet flow record-> TCP
connection btw X and Y = Z bytes), we might as well add a count field.
(This will requires modifications to the report specifications, but
there are no technical hurdles other than that).

> 
> 
> >Reasons for inclusion of msg field:
> >- No need to define a separate IDS superservice.
> >- That information is already mixed in serveral firewall products'
> >  logs because of the WELF format (it really contains three kind of
> >  information: packets dropped, proxy requests, connections, and IDS
> >  kind of messages).
> >
> >Reason against:
> >- Semantics between an IDS and packet filters are different.
> 
> 
> I'd go for as much integration as practically possible ...
> maintenance will be easier!
> 

I also think that it isn't really worth it to have a separate IDS
service if we add the msg field. This would make the firewall
superservice reports more versatile. You could also compare easily what
the IDS and the firewall say about the same event (by comparing the two
daily reports for example).

Other opinions?

-- 
Francis J. Lacoste
francis at Contre.COM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20020112/ecbda2fd/attachment.bin