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