[Bro] DPD or binpac on kernel-level
nweaver at ICSI.Berkeley.EDU
Sun Dec 23 10:30:58 PST 2007
Additionally, if you want to do something like this, I'd recommend
something more along the lines as follows:
Once a protocol is identified, or identification fails, you can put it
on a fash path. But until then, you want a slow path.
So you can use a shunt or shunt-style strategy. Either in software in
Click (which DOES run in the kernel) or in hardware (we have
prototypes in progress, but nothing I'd trust for production) you have
a cache of flow records. (For both you want it as a cache, so you can
statically allocate all resources).
These flow records are sent through the fast path (eithe directly or
with whatever shaping), with all other records going to the slow path,
user level analysis.
For DPD this works VERY well, as almost all of the traffic ends up on
the fast path.
On Sat, Dec 22, 2007 at 10:17:01PM +0100, Christian Kreibich composed:
> Hi Dongsu,
> On Tue, 2007-12-18 at 20:50 +0100, Dongsu Park wrote:
> > Hi,
> > is there any implementation of DPD or binpac on kernel-level,
> > for instance on Linux netfilter?
> > If not, do you have any plan for it?
> No. Primarily because we have no concrete reason to do so, and also
> because it'd very likely incur a world of pain -- C++ in kernel space is
> a thorny issue (the least technical obstacle is probably the fact that
> the STL isn't available, but much more subtle issues abound). Also
> notice that DPD and BinPAC are very different beasts. DPD's purpose is
> to detect likely protocols in flows, while BinPAC's purpose is to
> produce protocol parsers written in a high-level language. In Bro, we
> use BinPAC-generated parsers to confirm/reject the potential protocol
> identifications that DPD provides.
> > I think DPD and binpac are excellent implementations, but they currently
> > depend on Bro IDS. They would be more useful if they could be combined
> > into kernel-level firewalls, with enabling detected packets to be dropped
> > immediately.
> Thanks for the praise. What you're saying is no doubt true, though the
> issue is not primarily about kernel space, but Bro-independent use in
> general. In fact, we are surprised that many other tools for which
> accurate protocol identification is crucial haven't yet adopted the
> > As far as I know, L7-filter <http://l7-filter.sourceforge.net> does
> > similar jobs. It seems to be interesting if DPD/binpac can be ported to
> > kernel modules on L7-filter, or something like that.
> Surely it *could* be done, but the existence of L7 (which is great)
> provides another reason for us not to go down that road.
> Bro mailing list
> bro at bro-ids.org
Nicholas C. Weaver nweaver at icsi.berkeley.edu
This message has been ROT-13 encrypted twice for higher security.
More information about the Bro