<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Nftables on To Linux and beyond !</title>
    <link>https://home.regit.org/tags/nftables/</link>
    <description>Recent content in Nftables on To Linux and beyond !</description>
    <generator>Hugo</generator>
    <language>fr</language>
    <lastBuildDate>Wed, 24 Sep 2014 12:12:25 +0000</lastBuildDate>
    <atom:link href="https://home.regit.org/feed/tags/nftables/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Using DOM with nftables</title>
      <link>https://home.regit.org/2014/09/using-dom-with-nftables/</link>
      <pubDate>Wed, 24 Sep 2014 12:12:25 +0000</pubDate>
      <guid>https://home.regit.org/2014/09/using-dom-with-nftables/</guid>
      <description>&lt;h4 id=&#34;dom-and-ssh-honeypot&#34;&gt;DOM and SSH honeypot&lt;/h4&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/regit/DOM&#34;&gt;DOM&lt;/a&gt; is a solution comparable to &lt;a href=&#34;http://www.fail2ban.org/wiki/index.php/Main_Page&#34;&gt;fail2ban&lt;/a&gt; but it uses &lt;a href=&#34;http://suricata-ids.org/&#34;&gt;Suricata&lt;/a&gt; SSH log instead of SSH server logs. The goal of DOM is to redirect the attacker based on its SSH client version. This allows to send attacker to a honeypot like &lt;a href=&#34;https://home.regit.org/2014/06/pshitt-collect-passwords-used-in-ssh-bruteforce/&#34;&gt;pshitt&lt;/a&gt; directly after the first attempt. And this can be done for a whole network as Suricata does not need to be on the targeted box.&lt;/p&gt;
&lt;h4 id=&#34;using-dom-with-nftables&#34;&gt;Using DOM with nftables&lt;/h4&gt;
&lt;p&gt;I’ve pushed a &lt;a href=&#34;https://github.com/regit/DOM/commit/d3fb3946b2b9c63cc638bad55b954e30706900d8&#34;&gt;basic nftables support&lt;/a&gt; to &lt;a href=&#34;https://github.com/regit/DOM&#34;&gt;DOM&lt;/a&gt;. Instead of adding element via ipset it uses a &lt;a href=&#34;http://wiki.nftables.org/wiki-nftables/index.php/Sets&#34;&gt;nftables set&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Suricata and Nftables</title>
      <link>https://home.regit.org/2014/02/suricata-and-nftables/</link>
      <pubDate>Wed, 05 Feb 2014 09:03:28 +0000</pubDate>
      <guid>https://home.regit.org/2014/02/suricata-and-nftables/</guid>
      <description>&lt;h4 id=&#34;iptables-and-suricata-as-ips&#34;&gt;Iptables and suricata as IPS&lt;/h4&gt;
&lt;p&gt;&lt;a href=&#34;https://home.regit.org/2011/01/building-a-suricata-compliant-ruleset/&#34;&gt;Building a Suricata ruleset&lt;/a&gt; with iptables has always been a complicated task when trying to combined the rules that are necessary for the IPS with the firewall rules. Suricata has always used &lt;a href=&#34;https://home.regit.org/2011/04/some-new-features-of-ips-mode-in-suricata-1-1beta2/&#34;&gt;Netfilter advanced features&lt;/a&gt; allowing some more or less tricky methods to be used.&lt;/p&gt;&lt;/p&gt;
&lt;p&gt;For the one not familiar with IPS using Netfilter, here’s a few starting points:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;IPS receives the packet coming from kernel via rules using the NFQUEUE target&lt;/li&gt;
&lt;li&gt;The IPS must received all packets of a given flow to be able to handle detection cleanly&lt;/li&gt;
&lt;li&gt;The NFQUEUE target is a terminal target: when the IPS verdicts a packet, it is or accepted (and leave current chain) &lt;/ol&gt; &lt;/p&gt;</description>
    </item>
    <item>
      <title>Why you will love nftables</title>
      <link>https://home.regit.org/2014/01/why-you-will-love-nftables/</link>
      <pubDate>Mon, 20 Jan 2014 11:57:35 +0000</pubDate>
      <guid>https://home.regit.org/2014/01/why-you-will-love-nftables/</guid>
      <description>&lt;h4 id=&#34;linux-313-is-out&#34;&gt;Linux 3.13 is out&lt;/h4&gt;
&lt;p&gt;Linux 3.13 is out bringing among other thing the first official release of &lt;a href=&#34;http://netfilter.org/projects/nftables/&#34;&gt;nftables&lt;/a&gt;. nftables is the project that aims to replace the existing {ip,ip6,arp,eb}tables framework aka iptables.&lt;br&gt;
nftables version in Linux 3.13 is not yet complete. Some important features are missing and will be introduced in the following Linux versions.&lt;br&gt;
It is already usable in most cases but a complete support (read nftables at a better level than iptables) should be available in Linux 3.15.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Pablo Neira Ayuso, nftables strikes back</title>
      <link>https://home.regit.org/2013/03/pablo-neira-ayuso-nftables-strikes-back/</link>
      <pubDate>Tue, 12 Mar 2013 10:13:42 +0000</pubDate>
      <guid>https://home.regit.org/2013/03/pablo-neira-ayuso-nftables-strikes-back/</guid>
      <description>&lt;h4 id=&#34;introduction&#34;&gt;Introduction&lt;/h4&gt;
&lt;p&gt;This is a new kernel packet filtering framework. The only change is on iptables. Netfilter hooks, connection tracking system, NAT are unchanged.&lt;br&gt;
It provides a backward compatibility. nftables was released in March 2009 by Patrick Mchardy. It has been revived in the precedent months by Pablo Neira Ayuso and other hackers.&lt;/p&gt;
&lt;h4 id=&#34;architecture&#34;&gt;Architecture&lt;/h4&gt;
&lt;p&gt;It uses a pseudo-state machine in kernel-space which is similar to BPF:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;4 registers: 4 general purpose (128 bits long each) + 1 verdict&lt;/li&gt;
&lt;li&gt;provides instruction set (which can be extended)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Here’s a example of existing instructions:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
