<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Well, I guess it’s possible. But if it’s in a home, does this apply? How do I tell if the packets are as such marked? Is there something I can use to examine the packets?<div><br></div><div>Then my question is how do I fix the tag? A how to would be ideal!<br><br><div id="AppleMailSignature">Sent from my iPad</div><div><br>On Mar 8, 2018, at 6:11 PM, Chris Boley <<a href="mailto:ilgtech75@gmail.com">ilgtech75@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div dir="auto">Albert, if you happen to be using this inline between an ISP service delivery switch and your firewall interface, ISP’s often tag their frames that they are sending you with a specific vlan ID. Or possibly if your IPS topology is designed where your scanning between two switches that might have been “trunks” where it’s tagging vlan ID’s to the frames; then You would need to enable the appropriate sysctl flags to tell your bridge to send tagged frames to IPTABLES. Otherwise it won’t do it and anything in the forward rule will be ignored. By default in Ubuntu those flags aren’t enabled. That was what I was guessing may be happening to you.</div><br><div class="gmail_quote"><div>On Thu, Mar 8, 2018 at 5:43 PM Albert E 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">I don’t think so. How can I tell if the packets are actually getting to Suricata??<br><br><div id="m_1966405105212432303AppleMailSignature">Sent from my iPhone</div></div><div dir="auto"><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:0 0 0 .8ex;border-left:1px #ccc solid;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></blockquote></div></div>
</div></blockquote></div></body></html>