[Oisf-devel] innovation

[Eric Leblond]

Hi,

Le mercredi 11 août 2010 à 13:42 -0400, m a écrit :
> Surricata; Innovation. Maybe this suggestion will help.
> I only suggest this from my experience with linux networking. As far as 
> BSD, MAC, and Windows I humbly leave others to ponder solutions.
> 
> I am using Suricata with the ET rules and it works but queuing in 
> iptables rules breaks the logical flow.
> That is not innovative... It is ugly. I don't like that mess.
> 
> On linux platforms Suricata could be implemented as a kernel module and 
> integrated into the system, instead of running in user space.
> It would be much more efficient, especially when used as an IPS.

Well, why not. But some work will be necessary to limit memory usage
(kernel will not like allocation of a few hundred megas ;) and I don't
speak about the effect of a crash :/

Seriously, I don't think this is a good idea.

> Then a new xtables target and match, would allow a direct interface 
> using iptables rules, instead of using the current queuing mechanism 
> which is not very flexible and returns no information.

I'm known for being a heavy queuing mechanism user but I don't think it
influence me on saying I don't see the point here: suricata decide to
drop the packet and it has plenty of information when doing this. It can
thus log what it want.

> Instead of using Suricata to handle disposition we would remove all 
> Suricata action code, and just return the packet with a reserved mark.
> Packets processed by Suricata rules would then be matched against the 
> mark and acted upon with an iptables match rule, while the rest continue 
> to traverse iptables rules. Logging of actions then becomes child play.

Here again, knowing well netfilter logging for being a ulogd2 commiter,
I don't see the point. When logging via Netfilter, the only field that
will be available for extensive information will be the log prefix.

If suricata is currently not able to log that it has dropped a packet.
It is a suricata problem that need to be solved into suricata.

> I do similar stuff with the GeoIP and ipset modules and that works fast 
> and fine. I am sure doing this is the best idea, for Suricata on linux.
> 
> This linux modular code can be a fork from the main code so the project 
> is not changed from it's original form. Won't break anything.
> 
> The person to discuss this with is Jan Engelhardt, who would also make a 
> great member of the Suricata team on behalf of linux. (begging helps;-)

Jan's contribution could be valuable indeed.

The main issue with nfqueue is performance. As discussed with Victor
Julien once, it is not possible to exceed a certain number of packets
per second (even if hardware is improved). This limit is quiet annoying
and a better/faster queuing mechanism has to be developped to fix this
issue.

BR,
-- 
Eric LEBLOND, CTO
-----------------------------------
Tél. +33 (0)1 40 24 65 00 - Mob. +33 (0)6 70 30 90 32
eleblond at edenwall.com     - http://www.edenwall.com