<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Engine on Inliniac</title>
    <link>https://inliniac.net/blog/tag/engine/</link>
    <description>Recent content in Engine on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2009 18:30:37 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/engine/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>OISF engine development update(2)</title>
      <link>https://inliniac.net/blog/2009/09/30/oisf-engine-development-update2/</link>
      <pubDate>Wed, 30 Sep 2009 18:30:37 +0000</pubDate>
      <guid>https://inliniac.net/blog/2009/09/30/oisf-engine-development-update2/</guid>
      <description>&lt;p&gt;Another quick update on the development of the OISF engine. Overall development is going great. Basics like signature keywords, stream reassembly, ip defragmentation are nearing completion. Unified1 + barnyard was already working for quite some time, but now we also have unified2 compatible output. I&amp;rsquo;ve tested this to work with barnyard2 and Sguil which works nicely.&lt;/p&gt;&#xA;&lt;p&gt;We have the first versions of our new YAML based configuration format checked in, a brand new logging API, midstream pickup support in our Stream engine, native PFRING support and many other additions.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OISF engine development update</title>
      <link>https://inliniac.net/blog/2009/08/16/oisf-engine-development-update/</link>
      <pubDate>Sun, 16 Aug 2009 14:17:32 +0000</pubDate>
      <guid>https://inliniac.net/blog/2009/08/16/oisf-engine-development-update/</guid>
      <description>&lt;p&gt;The last month has been crazy busy. Development of the engine is progressing nicely. My own role has been assigning tasks to our coders, guiding them, reviewing their work, integrating it and of course write code. We currently have nine people coding, not all full time though, and are still looking for more coders.&lt;/p&gt;&#xA;&lt;p&gt;Progress has been made on a number of things: we have many more decoders, threading updates, a stats subsystem, stream tracking and reassembly, a L7 protocol parser framework and many more unittests. We&amp;rsquo;re working on OpenCL hardware accelaration, although we&amp;rsquo;re running into driver issues, so that may take some time before it&amp;rsquo;s usable.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OISF engine prototype: streams handling</title>
      <link>https://inliniac.net/blog/2009/03/31/oisf-engine-prototype-streams-handling/</link>
      <pubDate>Tue, 31 Mar 2009 15:36:27 +0000</pubDate>
      <guid>https://inliniac.net/blog/2009/03/31/oisf-engine-prototype-streams-handling/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been thinking about how to deal with streams in the OISF engine. We need to do stream reassembly to be able to handle spliced sessions, otherwise it would be very easy to evade detection. Snort traditionally used an approach of inspecting the packets individually and reassembling (part of) the stream in a pseudo packet, that was inspected mostly like a normal packet. Recent Snort versions, especially when Stream5 was introduced, have a so called stream api. This enables detection modules to control the reassembly better.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OISF engine prototype: threading</title>
      <link>https://inliniac.net/blog/2009/02/28/oisf-engine-prototype-threading/</link>
      <pubDate>Sat, 28 Feb 2009 20:38:28 +0000</pubDate>
      <guid>https://inliniac.net/blog/2009/02/28/oisf-engine-prototype-threading/</guid>
      <description>&lt;p&gt;In Januari I first wrote about my prototype code for the OISF engine. The first thing I started with when creating the code was the threading. The current code can run as a single thread or with many threads. In my normal testing I run with about 11 threads, 10 of which handle packets, 1 is a management thread.&lt;/p&gt;&#xA;&lt;p&gt;The basic principle in the threading is that a packet is always handled by one thread at a time only. The reason for this is that it saves a lot of locking issues. If there is more than one thread, the engine can handle multiple packete simultaniously.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OISF IDS/IPS engine prototype intro</title>
      <link>https://inliniac.net/blog/2009/01/07/oisf-ids-ips-engine-prototype-intro/</link>
      <pubDate>Wed, 07 Jan 2009 11:24:07 +0000</pubDate>
      <guid>https://inliniac.net/blog/2009/01/07/oisf-ids-ips-engine-prototype-intro/</guid>
      <description>&lt;p&gt;For over a year I&amp;rsquo;ve been working on a prototype implementation of a new IDS/IPS engine for the &lt;a href=&#34;http://www.openinfosecfoundation.org/&#34;&gt;Open Infosec Foundation&lt;/a&gt;. This is not necessarily going to be the engine we&amp;rsquo;ll be using in OISF, although it&amp;rsquo;s likely that at least some of the code will be used. Discussions about features for the engine are still ongoing ( &lt;a href=&#34;http://doc.emergingthreats.net/bin/view/Main/EngineFeatures&#34;&gt;wiki&lt;/a&gt;, &lt;a href=&#34;http://lists.openinfosecfoundation.org/mailman/listinfo/discussion&#34;&gt;list&lt;/a&gt;), once that settles down we&amp;rsquo;ll see whats usable and whats not. In the worst case I still think many parts like hashing functions, pattern matcher implementations, protocol decoders, etc can be used.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
