DPD or binpac on kernel-level

Zeek
1

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?

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.

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.

2

Hi Dongsu,

People have tried using binpac on systems other than Bro. The main
obstacle is to have a regular expression matching library, which
binpac-based analyzers rely on. If you have such a library that can be
used in-kernel, you are pretty close. Then you need a library to
handle dynamic memory allocation (if I understand kernel programming
correctly).

Ruoming

3

Hi Dongsu,

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
technology.

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.

Cheers,
Christian

4

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: