<div><div dir="auto">sudo iptables -nvL</div><div dir="auto">The subsequent output should show you incrementing values in your forward rule as you re-run the command several times. If it does not, then your packets are not being handled by IPTABLES as you had hoped.</div><br><div class="gmail_quote"><div>On Thu, Mar 8, 2018 at 9:48 PM Albert Whale <<a href="mailto:Albert.Whale@it-security-inc.com">Albert.Whale@it-security-inc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Ok, I tried the INPUT section for iptables to NFQUEUE, but still no luck.<div><br></div><div>How do I tell if packets make it to the nfqueue?</div><div><br></div><div>I’m beginning to think that I need to roll my own (compile) Suricata instead of installed the precompiled release.<br><br><div id="m_-4966250539629622938AppleMailSignature">Sent from my iPad</div></div></div><div dir="auto"><div><div><br>On Mar 8, 2018, at 8:10 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div dir="auto">I followed a similar guide, I’ll go back and read that one once I get home. it’s been working well for over a year, I also set the bypass flag, but that’s is mainly paranoia, in case it stops listening. I need packets to flow on the servers that suricata runs on (I get an alert, immediately, if not). </div><div dir="auto"><br></div><div>At home now, the docs are similar, i'm not sure why i chose the second option. I also use saltstack for all configurations and my states are:</div><div><br></div><div><div>nfqueue-input:</div><div> iptables.append:</div><div> - chain: INPUT</div><div> - jump: NFQUEUE</div><div> - queue-bypass: ''</div><div> - save: True</div><div> - require:</div><div> - sls: iptables</div><div><br></div><div>nfqueue-output:</div><div> iptables.append:</div><div> - chain: OUTPUT</div><div> - jump: NFQUEUE</div><div> - queue-bypass: ''</div><div> - save: True</div><div> - require:</div><div> - sls: iptables</div></div><div><br></div><div>so I ignore forward. I may not be helping, but i'm going to see on some of my staging servers what happens if i change to FORWARD only. </div><div><br></div><div>Hopefully good info for both of us. There are no bridged cards, this is configured on EC2 instances with no advanced networking, all instances that suricata is running on are public, or have at least a one public port.</div><div dir="auto"><br></div><br><div class="gmail_quote"><div>On Thu, Mar 8, 2018 at 6:58 PM Albert Whale <<a href="mailto:Albert.Whale@it-security-inc.com" target="_blank">Albert.Whale@it-security-inc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Jeff, I implemented the forward because of the guide here:<div><br></div><div><a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Setting_up_IPSinline_for_Linux" target="_blank">https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Setting_up_IPSinline_for_Linux</a></div><div><br></div><div>According to the Guide, the forward Is us3d to protect the network behind the IPS, the INPUT setting was for protecting the host. Did I misunderstand that?</div><div><br><div id="m_-4966250539629622938gmail-m_-6678855045576122569m_7668901592846320115AppleMailSignature">Sent from my iPad</div></div></div><div dir="auto"><div><div><br>On Mar 8, 2018, at 5:56 PM, Jeff Dyke <<a href="mailto:jeff.dyke@gmail.com" target="_blank">jeff.dyke@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>I'm not to sure how helpful this is, but do you see <div>8/3/2018 -- 22:12:59 - <Info> - NFQ running in standard ACCEPT/DROP mode<br></div><div>in your suricata.log (timing aside)<br></div><div>Also i attach this to my INPUT route, any reason you're only using FORWARD. Do you see any bytes and packets rising in FORWARD.</div><div><br></div><div>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 8, 2018 at 5:39 PM, Albert E Whale <span><<a href="mailto:Albert.Whale@it-security-inc.com" target="_blank">Albert.Whale@it-security-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I don’t think so. How can I tell if the packets are actually getting to Suricata??<br><br><div id="m_-4966250539629622938gmail-m_-6678855045576122569m_7668901592846320115m_2773172861794476218AppleMailSignature">Sent from my iPhone</div><div><div class="m_-4966250539629622938gmail-m_-6678855045576122569m_7668901592846320115h5"><div><br>On Mar 8, 2018, at 5:06 PM, Chris Boley <<a href="mailto:ilgtech75@gmail.com" target="_blank">ilgtech75@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div dir="auto">Sorry I replied directly the first time.</div><div dir="auto">Are the frames crossing the bridge tagged with vlan ID’s?</div><br><div class="gmail_quote"><div>On Thu, Mar 8, 2018 at 3:33 PM Albert Whale <<a href="mailto:Albert.Whale@it-security-inc.com" target="_blank">Albert.Whale@it-security-inc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am running Suricata 4.0.4, and attempting to run with the NFQ. I have<br>
AF-Packet working perfectly, but I wanted to run in IPS mode, and I<br>
understand that this is only available while using nfqueue. Here's the<br>
Startup log information.<br>
<br>
8/3/2018 -- 09:14:19 - <Notice> - This is Suricata version 4.0.4 RELEASE<br>
8/3/2018 -- 09:14:19 - <Info> - CPUs/cores online: 4<br>
8/3/2018 -- 09:14:19 - <Config> - luajit states preallocated: 128<br>
8/3/2018 -- 09:14:19 - <Config> - 'default' server has<br>
'request-body-minimal-inspect-size' se<br>
t to 31625 and 'request-body-inspect-window' set to 4241 after<br>
randomization.<br>
8/3/2018 -- 09:14:19 - <Config> - 'default' server has<br>
'response-body-minimal-inspect-size' s<br>
et to 41627 and 'response-body-inspect-window' set to 16218 after<br>
randomization.<br>
8/3/2018 -- 09:14:19 - <Config> - DNS request flood protection level: 500<br>
8/3/2018 -- 09:14:19 - <Config> - DNS per flow memcap (state-memcap): 524288<br>
8/3/2018 -- 09:14:19 - <Config> - DNS global memcap: 16777216<br>
8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled<br>
for modbus protocol.<br>
8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled<br>
for enip protocol.<br>
8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled<br>
for DNP3.<br>
8/3/2018 -- 09:14:19 - <Info> - Enabling fail-open on queue<br>
8/3/2018 -- 09:14:19 - <Info> - NFQ running in standard ACCEPT/DROP mode<br>
<br>
The IPTables has been configured as such:<br>
<br>
iptables -nL | grep -v DROP<br>
Chain INPUT (policy ACCEPT)<br>
target prot opt source destination<br>
<br>
Chain FORWARD (policy ACCEPT)<br>
target prot opt source destination<br>
NFQUEUE all -- <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> NFQUEUE num 0<br>
<br>
Chain OUTPUT (policy ACCEPT)<br>
target prot opt source destination<br>
<br>
<br>
I also have the following configuration setup for nfq:<br>
<br>
nfq:<br>
mode: accept<br>
repeat-mark: 1<br>
repeat-mask: 1<br>
bypass-mark: 1<br>
bypass-mask: 1<br>
route-queue: 2<br>
# batchcount: 20<br>
fail-open: yes<br>
<br>
This is running on Ubuntu: #35~16.04.1-Ubuntu<br>
<br>
As I mentioned, I successfully launched suricata inline (I have two<br>
bridged Ethernet interfaces) with af-packet, but I do not see it<br>
behaving as a True IPS, and while the nfq appears to launch, it is NOT<br>
processing any packets in the logs.<br>
<br>
Any suggestions where to look next?<br>
<br>
<br>
--<br>
--<br>
<br>
<br>
<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@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/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div></div>
</div></blockquote></div></div></div><br>_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@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/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a><br></blockquote></div><br></div>
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div></div></blockquote></div></div>