PROPOSAL: Modifications to firewall schema

[Wytze van der Raay]

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.

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.


 > ...

> One could argue that IDS represent a different kind of information
> than a packet filter. For example, a "SYN Flood" message really
> represents several packets. 
> 
> But again, if you read the "Implementation Notes" in the WELF
> converter you'll see that this is already the case for "permitted"
> "packet": WELF will log one event for after a connection with the
> bytes count of the service: 
> 
> ip=172.16.0.43 pri=6] id=firewall time="1998-08-02 16:54:24" fw=WebTrendsSample pri=6 proto=dns src=172.16.0.72 dst=204.147.80.5 rcvd=152
> 
> In that case, I had the choice of either dropping that information, or
> using it altough it isn't semantically correct.


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?


> 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!

-- wytze


-- 
To UNSUBSCRIBE, email to development-request at logreport.org with a subject of
"unsubscribe". Trouble? Send an email with subject "help" to
development-request at logreport.org