<p dir="ltr">Stan, that mechanism is exactly what I have described. This feature has been available for quite some time now.  </p>
<p dir="ltr">Good luck with your implementation.</p>
<p dir="ltr">David Sussens.</p>
<div class="gmail_quote">On 22 May 2017 17:14, "Stanford Prescott" <<a href="mailto:stan.prescott@gmail.com">stan.prescott@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you, David. That should be very helpful. I think I got confused by the article I read which I am thinking is a new feature that has been added to suricata which appears to be a way of marking traffic with different marks to return to iptables to process depending on what the mark is. Perhaps like both traffic to be accepted and dropped are returned to iptables to be processed depending on what the mark is?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 4:26 AM, David Sussens <span dir="ltr"><<a href="mailto:dsussens@gmail.com" target="_blank">dsussens@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Basically what needs to be done is the following:<br><br></div><div>1. In iptables:<br><br>-A INPUT -m mark ! --mark 1/1 -j NFQUEUE --queue-balance 0:3 --queue-bypass<br><br></div><div>You add the rule above.  This rule works as follows:<br><br></div><div>Traffic that is does not have a mark/mask of 1/1 is forwarded to suricata for processing.  Once Suricata is finished processing, the traffic is reinjected into the INPUT chain but this time the mark 1/1 is set, which means on the second round the trafffic is not forwarded to suricata and will skip on to the rules lower down in the INPUT chain.  Remember that traffic is only reinjected if it was not dropped by Suricata.  Thus, your marking does not have to be specified in the suricata rules at all and it is business as usual from that prespective.<br></div><div><br></div>2.  in suricata.yaml:<br><br>nfq:<br>  mode: <span style="background-color:rgb(106,168,79)">repeat<span></span></span><br>  repeat-mark: 1<br>  repeat-mask: 1<br>  route-queue: 2<br>  batchcount: 20<br>  fail-open: no<br><br></div>You change the nfq mode from accept to repeat this causes packets that were not rejected by Suricata to be reinjected into the appropriate chain. <br><br></div>This is how I am using it.  In my case I am doing this to ensure that traffic is first checked by Suricata, and then goes to the local Apache Inverse Proxy. <br><br></div>Hope this helps.<br><br></div>David Sussens. <br><div><div><div><div><div><br><br><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_7642545560719646851h5">On Sun, May 21, 2017 at 10:04 PM, Stanford Prescott <span dir="ltr"><<a href="mailto:stan.prescott@gmail.com" target="_blank">stan.prescott@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_7642545560719646851h5"><div dir="ltr">I ma trying to integrate Suricata 3.2.1 into our iptables firewall in IPS mode. We have have been using Snort in IDS mode but wanted to provide more filtering options. I like the possibility of using Suricata in IPS mode using nfq in repeat mode to return marked packets to the iptables table that sent the packets to Suricata for further processing. Snort doesn't seem to do this so we are trying to make the switch to Suricata.<div><br></div><div>I've been doing a lot of research to figure all of this out. I have read this excellent article about nfq and nfq_set_mark. <a href="https://home.regit.org/tag/suricata/page/4/" target="_blank">https://home.reg<wbr>it.org/tag/suricata/page/4/</a></div><div><br></div><div>To use iptables with mark and mask, the article indicates that the "nfq_set_mark" keyword needs to be added to the Suricata rules. How do I determine to what rules I add the keyword? Would I just add the keyword to every rule that Suricata is using as listed in suricata.yaml? Or is there a recommended set of rules to add the keyword? Or are there rule sets available that already have the keyword added to the rules?</div><div><br></div><div>Is Suricata able to set a mark for packets to be accepted and set a different mark for packets that need to be dropped or rejected?</div><div><br></div><div>Any other tips and suggestions for getting Suricata working in IPS mode working with iptables would be much appreciated.</div></div>
<br></div></div>______________________________<wbr>_________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundati<wbr>on.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/suppor<wbr>t/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfound<wbr>ation.org/mailman/listinfo/ois<wbr>f-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@<wbr>openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/<wbr>support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.<wbr>openinfosecfoundation.org/<wbr>mailman/listinfo/oisf-users</a><br>
<br></blockquote></div>