4:52 p.m.
Hi all,
I believe I'm going to post the first message in the list :D First of
all, I would like to say thak you to all the guys that have made it
possible to open source this great technology.
Our company has been following this effort since HyperScan was part
of Sensory Networks and at that time, they still used the FPGA based
card. Then, then they opted for software only solution and from there
went into Intel's arms.
At the time there was a Snort version prepared to run HyperScan right
away. I would liketo know if that software is still around, and
specially if its going to be open source or not too.
My point is, we plan to port Snort to use HyperScan, but if there is
already a starting ground it would for sure help such effort.
Again, congratulations. Regards
--
Jaime Nebrera - CTO
jnebrera(a)redBorder.net
8:31 a.m.
Thanks Jaime,
You are indeed the first poster. Thanks for your kind words.
We do have patches against some Open Source projects in varying degrees of readiness.
We're working on the process of releasing them and hope to have news in this area
soon. We are not saying "don't write your own patch" but there are
subtleties to doing this well that are best illustrated by us supplying code.
Some systems are more amenable to simple "use Hyperscan" patches than others.
Snort is a mixed case. It has a number of good integration points for the use of Hyperscan
(for literal matching and regular expressions) and has a pattern of "compile first,
run later" that fits Hyperscan nicely. On the negative side, a lot of the things
we've worked on in Hyperscan (streaming and bulk *regex* matching as opposed to bulk
literal matching) don't fit Snort's model at all.
The same argument fits many other systems: if you have a lot of regexes that you need to
scan, but work with the background assumption that "regex is slow and won't scale
or stream", your next steps are to work around regex, deemphasize it on your fast
path and/or design it out of your system entirely. We hope to influence people away from
that assumption over the long term, but there's a lot of code/rules/practices out
there based on it and we expect change to be slow.
Regards,
Geoff.
2:16 p.m.
El 23/10/15 a las 02:31, Langdale, Geoffrey escribió:
Thanks Jaime,
You are indeed the first poster. Thanks for your kind words.
:)
We do have patches against some Open Source projects in varying
degrees of readiness. We're working on the process of releasing them and hope to have
news in this area soon. We are not saying "don't write your own patch" but
there are subtleties to doing this well that are best illustrated by us supplying code.
I fully agree on this. This is why I asked.
Some systems are more amenable to simple "use Hyperscan"
patches than others. Snort is a mixed case. It has a number of good integration points for
the use of Hyperscan (for literal matching and regular expressions) and has a pattern of
"compile first, run later" that fits Hyperscan nicely. On the negative side, a
lot of the things we've worked on in Hyperscan (streaming and bulk *regex* matching as
opposed to bulk literal matching) don't fit Snort's model at all.
The same argument fits many other systems: if you have a lot of regexes that you need to
scan, but work with the background assumption that "regex is slow and won't scale
or stream", your next steps are to work around regex, deemphasize it on your fast
path and/or design it out of your system entirely. We hope to influence people away from
that assumption over the long term, but there's a lot of code/rules/practices out
there based on it and we expect change to be slow.
Indeed this is the case in many areas. Of course, Snort is designed
around asumptions that new times might not longer stand, either because
of software, new algorithms or hardware. Just to name one, you can see
how big change is DPDK and how is influencing new developments that just
want to go beyond the established rules. Or how huge was the change to
"multi core" CPUs that at first was just, "well, this is just a big SMP
box, nothing else to do", compared to current times.
Unfortunately, in many open source projects there is no real "surge"
to make the switch, and is hard to convince parties.
Still, for the case of Snort, Sourcefire / Cisco is making a big step
forward. The currently in alpha Snort++ seems adopting many (even if not
all) this new paradigms. Im pretty sure as you say a boost of the fast
path is doable right away in both Snort and Snort++, and with more time,
an integration of many capabilities of the current slow path into the
fast path could follow afterwards.
In our case, we would be more than willing to work with you on this.
Even if it means starting from a position that is not ideal, for sure it
will be much more helpful than doing it alltogether.
BTW, and in quite a different context, how about Suricata? I see you
have some nice recent benchmarks comparing HyperScan vs NonHyperScan
Suricata.
--
Jaime Nebrera - CTO
jnebrera(a)redBorder.net
2006
days inactive
2007
days old
2 comments
2 participants
participants (2)
-
Jaime Nebrera -
Langdale, Geoffrey