PROPOSAL: Modifications to firewall schema
Francis J. Lacoste
francis.lacoste at Contre.COM
Wed Jan 9 21:48:10 CET 2002
Proposal for modifications to the firewall superservice schema
==============================================================
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).
- snt_inft
Interface to which the packet was going (iptables has this
information, sometime the rcv_intf of ipchains log is really a
snt_intf).
- rule
Identifier of the rules that triggered that packet log. (Supported by
iptables, ipchains and welf). This would also makes interesting
reports: bytes-by-rule, packets-by-rule, etc.
IDS Integration
===============
There is also another field, which we might add:
- msg (attack?)
With such a field, most IDS could be integrated in the firewall
superservice. IDS logs (like snort for example) will usually contains
the following information:
src_ip, src_port, dst_ip, dst_port, msg
WELF logs also contains that type of information. Those logs will
contains things like "SYN Flood", "SubSeven Attack", etc.
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.
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.
--
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/20020109/34016f57/attachment.bin
More information about the Development
mailing list