<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Nfqueue on Inliniac</title>
    <link>https://inliniac.net/blog/tag/nfqueue/</link>
    <description>Recent content in Nfqueue on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Thu, 18 Sep 2008 11:32:40 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/nfqueue/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Snort_inline load balancing</title>
      <link>https://inliniac.net/blog/2008/09/18/snort_inline-load-balancing/</link>
      <pubDate>Thu, 18 Sep 2008 11:32:40 +0000</pubDate>
      <guid>https://inliniac.net/blog/2008/09/18/snort_inline-load-balancing/</guid>
      <description>&lt;p&gt;Dave Remien of &lt;a href=&#34;http://www.nitrosecurity.com/&#34;&gt;NitroSecurity&lt;/a&gt; created a patch that &amp;ldquo;implements a relatively simple form of (IPV4) load balancing&amp;rdquo; between multiple Snort_inline processes using Nfqueue. Here is what it does:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;1. Load balancing. The bottom half of the source and dest addresses are added together, and mod&amp;rsquo;d with the number of &amp;ldquo;load-balancing&amp;rdquo; snorts you desire to run. This means that traffic stays with a particular snort, so that state is maintained.&lt;/p&gt;&#xA;&lt;p&gt;2. Because you can run many snorts (presumably on many CPUs), you can now take advantage of that super-hooty 16way box and those 10 gig NICs you just got your hands on&amp;hellip;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Improving Snort_inline&#39;s NFQ performance</title>
      <link>https://inliniac.net/blog/2008/01/23/improving-snort_inlines-nfq-performance/</link>
      <pubDate>Wed, 23 Jan 2008 15:27:29 +0000</pubDate>
      <guid>https://inliniac.net/blog/2008/01/23/improving-snort_inlines-nfq-performance/</guid>
      <description>&lt;p&gt;When using Snort_inline with NFQ support, it&amp;rsquo;s likely that at some point you&amp;rsquo;ve seen messages like these on the console: &lt;em&gt;packet recv contents failure: No buffer space available&lt;/em&gt;. When the messages are appearing Snort_inline slows down significantly. I&amp;rsquo;ve been trying to find out why.&lt;/p&gt;&#xA;&lt;p&gt;There are a number of setting that influence NFQ performance. One of them is the NFQ queue maximum length. This is a value in packets. Snort_inline takes an argument to modify the buffer length: &amp;ndash;queue-maxlen 5000 (note: there are two dashes before queue-maxlen).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Multiple Snort_inline processes with Vuurmuur</title>
      <link>https://inliniac.net/blog/2007/11/12/multiple-snort_inline-processes-with-vuurmuur/</link>
      <pubDate>Mon, 12 Nov 2007 21:29:58 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/11/12/multiple-snort_inline-processes-with-vuurmuur/</guid>
      <description>&lt;p&gt;One of the cool things of the &lt;a href=&#34;http://snort-inline.sf.net/&#34;&gt;Snort_inline&lt;/a&gt; project is the support for NFQUEUE. NFQUEUE is the new queuing mechanism to push packets from the kernel to userspace so a userspace program can issue a verdict on it. What makes NFQUEUE cooler than it&amp;rsquo;s predecessor ip_queue is that it supports multiple queue&amp;rsquo;s. This means that there can be more than one Snort_inline process inspecting and judging traffic. The challenge is to make sure that each Snort_inline instance sees all traffic belonging to a certain connection so Snort_inline can do stateful inspection on it. Luckily, &lt;a href=&#34;http://www.vuurmuur.org/&#34;&gt;Vuurmuur&lt;/a&gt; makes it very easy.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Vuurmuur developments</title>
      <link>https://inliniac.net/blog/2007/09/17/vuurmuur-developments-2/</link>
      <pubDate>Mon, 17 Sep 2007 15:34:49 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/09/17/vuurmuur-developments-2/</guid>
      <description>&lt;p&gt;Last weeks I&amp;rsquo;ve spend many hours on my &lt;a href=&#34;http://www.vuurmuur.org/&#34;&gt;Vuurmuur Firewall project&lt;/a&gt;. First I&amp;rsquo;ve been improving the code to prepare for a new release. I&amp;rsquo;ve added NFQUEUE support to Vuurmuur, so I could use it with nfnetlink enabled Snort_inline. Also the connection killing has been improved. The rules limit options were extended, to allow more flexibility.&lt;/p&gt;&#xA;&lt;p&gt;Second, with the great help of Adi Kriegisch, I&amp;rsquo;ve been working on setting up a new build server for Debian and Ubuntu packages. Credits mostly go to Adi, who did most of the work &lt;strong&gt;and&lt;/strong&gt; hosts the server. So many thanks to Adi! The new build server supports all version of Debian from Sarge up and of Ubuntu from Dapper and up.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Compiling Snort_inline with NFQUEUE support on Ubuntu</title>
      <link>https://inliniac.net/blog/2007/06/26/compiling-snort_inline-with-nfqueue-support-on-ubuntu/</link>
      <pubDate>Tue, 26 Jun 2007 15:59:21 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/06/26/compiling-snort_inline-with-nfqueue-support-on-ubuntu/</guid>
      <description>&lt;p&gt;I needed to setup the right libraries for Snort_inline development on my fresh Ubuntu Feisty installation, so I decided to write down the procedure for those who think compiling Snort_inline from source is hard. :)&lt;/p&gt;&#xA;&lt;p&gt;Make sure you have build-essential package installed. This makes sure you have a compiler and development packages for glibc and other important libraries. I&amp;rsquo;m installing the libraries from source to get the latest versions because the latest versions are more stable and perform better than the versions included in Feisty. I&amp;rsquo;m installing them into /usr because some programs like them there best.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Vuurmuur NFQUEUE support</title>
      <link>https://inliniac.net/blog/2007/05/22/vuurmuur-nfqueue-support/</link>
      <pubDate>Tue, 22 May 2007 13:21:23 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/05/22/vuurmuur-nfqueue-support/</guid>
      <description>&lt;p&gt;Vuurmuur supported the QUEUE target for a while already, even though it needed a little bit of a hack to handle the &lt;em&gt;state&lt;/em&gt;. This is because the iptables ruleset Vuurmuur creates is quite simple: after a few general protection rules it starts by accepting traffic with the state &lt;em&gt;established&lt;/em&gt;. Since there is no way to say &amp;lsquo;queue established traffic that was queued before&amp;rsquo; in iptables I decided to use traffic marking to distinguish between traffic to be queued or accepted. But there was a problem with this approach. I didn&amp;rsquo;t want to cripple the marking of traffic for other purposes, such as traffic shaping and routing, so I decided to use mark-ranges to either queue or accept:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Snort_inline updated to 2.6.1.4 in SVN</title>
      <link>https://inliniac.net/blog/2007/04/20/snort_inline-updated-to-2614-in-svn/</link>
      <pubDate>Fri, 20 Apr 2007 16:47:33 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/04/20/snort_inline-updated-to-2614-in-svn/</guid>
      <description>&lt;p&gt;After moving, which went fine, I now finally have some real coding time again. The last week I have been updating and fixing various parts of Snort_inline. The most important change was the update to Snort version 2.6.1.4, which contains security fixes. William also found an issue with the Stream4inline code. The issue was that the memcap that the admin sets to limit the amount of memory used by stream4 wasn&amp;rsquo;t properly enforced.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
