[Oisf-devel] innovation

[m]

Eric Leblond wrote:
> 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.
> 

Suricata memory use is not very heavy, kernel or user space.
Using the IPS to process unfiltered traffic would surely cause overload.
If you block unserved ports and source ports like 6000 and 12200 you
don't need to process many packets at all.
Suricata belongs after basic filtering to start with.
90 percent of the Snort/Suricata rules are a useless waste of CPU for
most machines and should only be used selectively.
Implementation is everything.

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

I am suggesting iptables is better suited to handle all actions and let
Suricata only do detection. There is nothing to stop Suricata from
logging references however it can't use ulog2;-)

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

Yes, logging is a big issue. Suricata cannot say what action it took!
If a DROP is done in an iptables rule, it can be logged as such.
Likewise blacklisting to a ipset can be done with an iptables rule
but Suricata has no means to stop a constant stream of attacks.

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

No, the main issue with nfqueue is that it is a terminating target and
diverts the packet to the next table, instead of going to the next rule
in the table.
The kernel can buffer packets pretty fast, that's it's specialty.

> 
> BR,

Thanks for the feedback Eric.