On Dec 02, 2009, Fred Leeflang wrote:

> 2009/12/2 Michael Rash <m...@cipherdyne.org>:
> > On Dec 01, 2009, Fred Leeflang wrote:
> >
> >> Hi,
> >
> > Hello,
> >
> >> We've recently hacked NFLOG support into vuurmuur. An old-ish writeup
> >> of making psad work together with vuurmuur is here:
> >> http://vuurmuur.org/trac/wiki/PSAD
> >>
> >> I tried to make psad work with vuurmuur/nflog again but there are two
> >> issues stopping me from doing so:
> >>
> >> - I could not find any NFLOG support in psad. Maybe I've missed it. Is
> >> it in there or are there any plans to hack it in psad?
> >> - the netfilter core apparently does not do multicasting to multiple
> >> applications listening to the same nflog-group.
> >>
> >> If there's no nflog support in psad but it's desirable I would like to
> >> help as I have gained some experience with it (see
> >> http://wordpress.3dn.nl/2009/11/25/iptabes-nflog-support-in-vuurmuur/)
> >
> > There is no support currently in psad for NFLOG, but I think that
> > would be an interesting feature.  I suppose the question would be
> > whether to write a perl XS extension of libnetfilter_log (since a
> > quick look at CPAN didn't turn up anything) so that psad can handle
> > the data from the netlink socket itself, or if it would be better
> > to have a lightweight C application that takes the data from the
> > netlink socket and writes iptables LOG formatted data to a file or
> > to stdout.  The later would certainly be easier (especially when
> > ulog2 is ready for general release I think), but do you see a
> > compelling reason to have psad itself receive data from the netlink
> > socket?
> 
> Hi Michael,

Hi Fred,

> We've contemplated using ulogd2's syslog emulation ourselves but
> decided against it since it would introduce another dependency. It
> certainly works, I've tried it out and have found no problems with
> it at all, in fact I used some of the ulogd2 code as example code
> for implementing NFLOG in vuurmuur.

Understood.

> With the NFLOG target being unicast and logfiles by their nature
> being 'multicast', it certainly would be easier to just use the ulogd2
> output files. I think I have to think about this a little longer.
> 
> The only compelling reason I could see to have psad itself receive data
> from the netlink socket is speed (from a general point of view) and
> easier integration (from vuurmuur's point of view).

Ok.  psad makes an implicit assumption that the iptables policy has been
tuned to a reasonable degree in order to cut down on performance concerns.
That is, it assumes that traffic that is supposed to be accepted is not
logged.  This leaves the stuff that is dropped, and the limit target can
help here if one is concerned about floods and the like.  Attacks over
accepted traffic can still be detected by fwsnort in established
connections, and psad performs fairly well even at high rates of logs
coming out of iptables.  I suppose the same logic would apply to policies
that use the NFLOG target, unless the goal would be to turn psad itself
into an IDS that inspects the application layer (which would be possible
once packets are received via netlink, but this is not exactly what psad
was designed for).

I would be interested to hear any other opinions on anything above.

Thanks,

--Mike


> -Fred
> 
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> psad-discuss mailing list
> psad-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/psad-discuss

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
psad-discuss mailing list
psad-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/psad-discuss

Reply via email to