how to hack DNS name lookups in iptables and firewall DLF conversion? (was: Re: adding resolved hostnames to ...)

[Francis J. Lacoste]

Hello Joost,

First of all, since there are already 'from_host' and 'to_host' fields
in the base firewall schema, you couldn't really implement your feature
using an ExtendedSchema (and a ExtendedFieldsCreator module). Beside, we
are going to completely overhaul those aspects (ExtendedSchema et all)
next month, so better not work with that API.

So the best place for now to implement the feature is in the
DlfConverter itself. A good idea would be to implement the feature in
the Firewall.pm module so that other Firewall converters can take
advantage of that functionality.

As far as "configurable" DlfConverter goes, you have two choices. You
can either make it a global option (which is what is supported in
release 1.4) or you can make it a DlfConverter option (only supported in
CVS and upcoming 1.5 release).

In the first case, you take take a look at doc/examples. You will
find the way to access the configuration data in the
MyConverter::init_dlf_converter method and the way to hook it in the
Lire configuration process in the files myconverter_cfg_default.xml
and myconverter_cfg_spec.xml. More details can be found in
doc/examples/README.

An important limitation is that you will need to set an appropriate
'section' attribute if you want your option to appear in lr_config.

The 1.5 way to implement it would be to specifically register your
DlfConverter configuration properties. In the new lire(1) command a
<...> button appears when the selected DlfConverter has configuration
properties defined. The user selected properties are also now passed as
second parameter to the init_dlf_converter() method. 

To register configuration data for a DlfConverter in 1.5, you define
a <lrcmsl:record> element named <your_converter_name>_properties. This
record can now contains any number of configuration specification
elements. They will be displayed in a form for the user to fill in in
the user interface. The configuration data that should be use in the
current Dlf conversion process is passed as an hash reference in the
second parameter to the init_dlf_converter() method.

I'll update to example to show how to use that new paradigm for the 1.5
release (expected around the end of next week).

Hope this help you getting started.

On Sun, 2004-03-21 at 17:07, Joost van Baal wrote:
> On Sun, Mar 21, 2004 at 07:18:45PM +0100, Joost van Baal wrote:
> > 
> > I've been trying to enhance the iptables converter and Lire firewall
> > reports, to deal with resolved hostnames next to IP adresses in the DLF.
> > 
> > My initial idea was to convert logs to ascii-based DLF, do the resolving
> > in the DLF file, and feed this enhanced DLF to the rest of the Lire
> > processing chain.  However, this seems no longer possible: we are no
> > longer supporting plain ascii DLF's.  I guess I'll need to get the
> > iptables convertor fill the from_host and to_host fields some way.
> > Perhaps define an extra extended Firewall schema?
> 
> OK, I've converted iptables2dlf to the new module-based API (code is in
> CVS (untested....))  Now, I could get IptablesDlfConverter.pm do a
> resolver lookup for every IP address found in the raw log, and write
> these to from_host and to_host.  However, this is quite drastic: it
> causes quite some load and network traffic.  I guess this could better
> be configurable, and disabled by default.  Any good ideas on how to set
> this up?  There aren't any configurable converters yet, are they?  Could
> this better be implemented in an extra step in the 2dlf phase, perhaps?
> 
> Ideas welcome.
> 
> Bye,
> 
> Joost
Kind regards,

Francis J. Lacoste

-- 
Francis J. Lacoste              . .           http://www.logreport.org
/^LogReport$/               . .               flacoste at logreport.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.logreport.org/pipermail/development/attachments/20040325/7351eed5/attachment.bin