<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Stream-Reassembly on Inliniac</title>
    <link>https://inliniac.net/blog/tag/stream-reassembly/</link>
    <description>Recent content in Stream-Reassembly on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 31 Jan 2011 20:51:25 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/stream-reassembly/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Suricata IPS improvements</title>
      <link>https://inliniac.net/blog/2011/01/31/suricata-ips-improvements/</link>
      <pubDate>Mon, 31 Jan 2011 20:51:25 +0000</pubDate>
      <guid>https://inliniac.net/blog/2011/01/31/suricata-ips-improvements/</guid>
      <description>&lt;p&gt;January has been a productive month for Suricata, especially for the IPS part of it. I&amp;rsquo;ve quite some time on adding support to the stream engine to operate differently when running inline. This was needed as dropping attacks found in the reassembled stream or the application layer was not reliable. Up until now the stream engine would offer the reassembled stream to the detection engine as soon as it was ACK&amp;rsquo;d. This meant that by definition the packets containing the data had already passed the IPS device. Simply switching to sending un-ACK&amp;rsquo;d data to the detection engine would have it&amp;rsquo;s own set of issues.&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>
  </channel>
</rss>
