Suricata Not Blocking legacy mode

everfree

My IPS is transparent mode firewall, I must use custom passlist. This is 3G realtime and 800000 session.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

My IPS is transparent mode firewall, I must use custom passlist.

Well, in that case my comment above applies. Your custom pass list is too broad and thus is whitelisting a very wide range of IP address space. That's why you are not seeing blocks on stuff you think should block. The custom blocking engine also depends on an internal API in the Suricata binary for a Radix Tree. That Radix Tree holds the pass list IP addresses. Perhaps your large netblock ranges and what appear to be nested blocks are tripping up the built-in Radix Tree code in Suricata.

everfree

between the 2 years, I never meet this issue. do you have email? I send config to you.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

between the 2 years, I never meet this issue.

Well, you were either lucky or you have changed something. Have you made zero changes to your Pass List over the last two years, or have you added to it over the last two years? If you have continued to add to it, perhaps you now have reached a tipping point ???

everfree

between the 2 years, I only add whitelist to my custom passlist, and disable some FP rules.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

I only add whitelist to my custom passlist, and disable some FP rules.

This could be what caused your issue: I only add whitelist to my custom passlist

Your Pass List is now too large in terms of IP address space it has whitelisted. That's why I am saying cut it back to just your local networks (meaning just those networks behind your firewall).

What I am telling you is that your current custom list is whitelisting large chunks of Internet IP space. I doubt that is what you really need to have going on. It will cause broad ranges of IPs to not be blocked. I have not taken the time to calcuate out each and every subnet you have listed, but when I see /11 and /16 blocks that's an awful lot of whitelist IP space!

everfree

Can i downgrade suricata package to test?

So many happy memories between the past 2 years.

I wish i can use old version.

everfree

Now I enable 3 categories rules. It include ET MALWARE,ET MOBILE_MALWARE and ET TROJAN. Because the 3 categories have bad dst ip. I disable deny both, select deny dst. It works.

At least, there is some help......

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

Can i downgrade suricata package to test?

So many happy memories between the past 2 years.

I wish i can use old version.

No, there is no archive of older package versions. The pfSense package repos only contain the latest version of a package. Even if you did find a zipped package archive someplace of an older version, you likely would not be able to get it to install due to dependencies on other package versions. In other words, that older Suricata version would want older versions of all its supporting packages. Installing those older package versions could easily break your firewall.

bmeeks

As an experiment, why don't you try Snort instead of Suricata? Since you are using Legacy Mode blocking, they will offer the same level of protection. Snort can actually support more rules as it will correctly load all of the Snort Subscriber Rules and Emerging Threats Rules. Suricata does not support several Snort Subscriber Rules keywords and will not load all of the Snort Subscriber rules.

You can copy-paste your custom pass list content into a temp file and then copy-paste it back into the same type of custom pass list in Snort. The GUI parts of the two packages are almost identical in form and function.

I'm suggesting this because the one possible area where there could be a problem is within an internal piece of Suricata binary code called the Radix Tree API (all of that code comes from upstream and I do not alter it). My custom blocking plugin used for Legacy Mode blocking uses that Radix Tree API to store the pass list IP addresses and network blocks. There are API calls into the Radix Tree code that allow you to test if a given IP address matches a network or IP subnet that is defined in the Radix Tree. Snort uses a completely different type of Radix Tree technology, but does the same thing.

That Radix Tree code within the Suricata binary source code is fairly complex. Debugging it would not be for the faint of heart. You can examine the C source code in the files util-radix-tree.c and util-radix-tree.h within the Suricata source code tarball. You can download that source code tarball here.

It is very possible that some of the overlapping netblock ranges in your custom pass list are confusing the Radix Tree code. For example, these three entries have some overlap:

61.56.0.0/20
61.56.4.0/24
61.56.8.0/21

You only need to provide a single block like this:

61.56.0.0/20

That netblock covers all hosts within this range:

61.56.0.1 - 61.56.15.254

So see how your 61.56.4.0 and 61.56.8.0 networks are already contained within your larger 61.56.0.0 netblock? If you actually want that 61.56.0.0/20 entry, then you don't need the other two 61.56.4.0/24 and 61.56.8.0/21 entries.

You can use one of the widely available IP subnet calculators on the web to test your various IP blocks. Here is one I used for this example.

everfree

Snort has the same issue, this is deny BOTH, 4.16.0.0/16 is not in my passlist.

bmeeks

Snort uses a different code base for determining if one of the IP addresses in a packet is within a specified pass list. So it would not share the same defect, if a defect exists, as the Suricata Radix Tree code. I'm thinking it is something with your setup. I believe you mentioned earlier in this thread that the firewall was in transparent mode. That is not a configuration I have ever tested either Snort or Suricata with, and it is not really a supported setup. It might work, but I have never tested it. One thing that might be going on is the automatic pass list code within the blocking module may be getting confused by the transparent mode operation. That code automatically asks FreeBSD for the assigned interface IP addresses and adds those to an internal pass list. That prevents the firewall interface IPs from ever getting blocked. With normal firewall configurations, where WAN and LAN have separate IP subnets assigned to them, that works fine. The code may be getting tripped up with transparent mode as it was not designed to anticipate that configuration. This automatic internal pass list was code was added maybe two or three years ago. I would have to dig through past revisions to see exactly when it was added.

Do your NICs support Suricata Inline IPS operation? If so, configure that mode. It does not use Pass Lists. Instead, if you want to whitelist individual IP addresses or entire network subnets, you do that using the IP Reputation tab. That mode might be better in your case.

everfree

Hi bmeeks,
I add Assign Categories File, categories.txt and Assign IP Reputation Lists, pass.txt, (Suricata)
Next step is what i can do????Legacy block mode???I don't know what is reputation score. I use 127(1-127)

categories.txt

1,GSN,Government Service Network
2,TANET,Taiwan Academic Network
3,NTCT,Nantou Academic Network
4,Whitelist,NTCT Passlist

pass.txt

61.56.0.0/20,1,127
61.56.4.0/24,1,127
61.56.8.0/21,1,127
61.57.32.0/19,1,127
61.57.54.0/23,1,127
61.57.56.0/23,1,127
61.60.20.0/24,1,127
61.60.21.0/24,1,127
61.60.22.0/24,1,127
61.60.29.0/24,1,127
61.60.32.0/23,1,127
61.60.34.0/24,1,127
61.60.92.0/24,1,127
61.60.93.0/24,1,127
61.60.94.0/23,1,127
61.60.96.0/24,1,127
61.60.97.0/24,1,127
61.60.122.0/23,1,127
61.67.64.0/19,1,127
61.67.93.0/24,1,127
61.67.94.0/24,1,127
61.67.95.0/24,1,127
117.56.0.0/16,1,127
117.56.6.0/24,1,127
117.56.30.0/24,1,127
117.56.79.0/24,1,127
117.56.104.0/23,1,127
117.56.106.0/23,1,127
117.56.108.0/24,1,127
117.56.110.0/24,1,127
117.56.111.0/24,1,127
117.56.112.0/24,1,127
117.56.113.0/24,1,127
117.56.118.0/23,1,127
117.56.152.0/23,1,127
117.56.161.0/24,1,127
117.56.238.0/24,1,127
117.56.239.0/24,1,127
117.56.244.0/23,1,127
124.199.64.0/19,1,127
124.199.96.0/20,1,127
124.199.108.0/23,1,127
124.199.110.0/23,1,127
127.0.0.1/32,1,127
163.22.49.26/32,1,127
163.22.49.28/32,1,127
163.22.168.0/24,1,127
163.29.0.0/16,1,127
168.95.1.1/32,1,127
168.95.192.1/32,1,127
210.69.0.0/16,1,127
210.69.61.0/24,1,127
210.241.0.0/17,1,127
210.241.57.0/24,1,127
210.241.90.0/24,1,127
210.241.91.0/24,1,127
210.241.96.0/24,1,127
210.241.110.0/24,1,127
211.79.128.0/19,1,127
211.79.136.0/24,1,127
211.79.137.0/24,1,127
211.79.153.0/24,1,127
211.79.154.0/24,1,127
211.79.160.0/19,1,127
211.79.163.0/24,1,127
211.79.184.0/23,1,127
211.79.189.0/24,1,127
223.200.0.0/16,1,127
8.8.4.4/32,2,127
8.8.8.8/32,2,127
120.96.0.0/11,2,127
127.0.0.1/32,2,127
134.208.0.0/16,2,127
140.109.0.0/16,2,127
140.110.0.0/15,2,127
140.111.64.0/18,2,127
140.112.0.0/12,2,127
140.113.0.0/12,2,127
140.114.0.0/12,2,127
140.115.0.0/12,2,127
140.116.0.0/12,2,127
140.117.0.0/16,2,127
140.119.0.0/16,2,127
140.128.0.0/13,2,127
140.136.0.0/15,2,127
140.138.0.0/16,2,127
163.13.0.0/16,2,127
163.14.0.0/15,2,127
163.15.0.0/16,2,127
163.16.0.0/13,2,127
163.17.0.0/19,2,127
163.18.0.0/16,2,127
163.19.0.0/16,2,127
163.20.0.0/16,2,127
163.21.0.0/19,2,127
163.22.0.0/19,2,127
163.22.49.26/32,2,127
163.22.49.28/32,2,127
163.22.168.0/24,2,127
163.23.0.0/16,2,127
163.24.0.0/14,2,127
163.25.0.0/18,2,127
163.26.0.0/16,2,127
163.27.0.0/16,2,127
163.28.0.0/16,2,127
163.30.0.0/15,2,127
163.32.0.0/16,2,127
168.95.1.1/32,2,127
168.95.192.1/32,2,127
192.192.0.0/16,2,127
203.64.0.0/16,2,127
203.68.0.0/16,2,127
203.71.0.0/16,2,127
203.72.0.0/16,2,127
210.59.0.0/17,2,127
210.60.0.0/16,2,127
210.62.64.0/19,2,127
210.62.224.0/20,2,127
210.62.240.0/21,2,127
210.62.247.0/24,2,127
210.67.248.0/21,2,127
210.70.0.0/16,2,127
210.71.0.0/17,2,127
210.240.0.0/16,2,127
210.243.0.0/18,2,127
163.22.0.0/16,3,127
8.8.4.4/32,4,127
8.8.8.8/32,4,127
59.120.208.208/32,4,127
59.120.235.235/32,4,127
59.120.242.111/32,4,127
59.125.1.114/32,4,127
59.125.1.115/32,4,127
59.125.14.1/32,4,127
59.125.86.119/32,4,127
59.126.9.231/32,4,127
59.126.182.150/32,4,127
61.221.80.11/32,4,127
66.249.64.0/19,4,127
118.163.8.90/32,4,127
118.163.209.137/32,4,127
125.227.186.86/32,4,127
127.0.0.1/32,4,127
140.110.141.23/32,4,127
140.112.57.111/32,4,127
140.112.65.202/32,4,127
140.112.65.206/32,4,127
140.116.221.36/32,4,127
140.116.221.37/32,4,127
140.116.221.38/32,4,127
140.116.221.39/32,4,127
163.22.49.26/32,4,127
163.22.49.28/32,4,127
163.22.168.0/24,4,127
168.95.1.1/32,4,127
168.95.192.1/32,4,127
175.183.83.82/32,4,127
175.183.91.163/32,4,127
202.169.169.32/32,4,127
203.74.121.45/32,4,127
210.61.91.43/32,4,127
210.61.91.44/32,4,127
210.70.125.132/32,4,127
210.71.213.29/32,4,127
210.243.49.81/32,4,127
211.20.66.150/32,4,127
211.21.2.211/32,4,127
211.21.204.80/32,4,127
211.21.204.82/32,4,127
211.75.165.114/32,4,127
211.75.194.79/32,4,127
211.79.113.33/32,4,127
220.132.30.215/32,4,127
220.134.59.158/32,4,127

bmeeks

Here is a link to Suricata's IP Reputation configuration. This is their official documentation site:

https://suricata.readthedocs.io/en/suricata-4.1.4/reputation/ipreputation/ip-reputation-format.html

You can also create your own custom PASS rules using the Custom Rules category on the RULES tab. In fact, after thinking it over, that is probably a better solution than my earlier advice to use IP REP.

Here is the documentation section on Pass Rules:

https://suricata.readthedocs.io/en/suricata-4.1.4/performance/ignoring-traffic.html#pass-rules

Pass rules will actually work better for emulating a Pass List. Sorry for steering you wrong on the IP REP. IP REP is used in Snort, but for Suricata, one or more PASS rules is better for whitelisting an IP address or entire network block.

I personally use Snort, so its features pop into my head first when I'm asked a question. I have to switch gears and think a moment about Suricata.

bmeeks

@everfree:
If you play around with the Legacy Blocking mode again in Suricata, there is a section of the suricata.log file that would be of interest to me since you are using a transparent firewall. I assume with that you are manually configuring a bridge on pfSense. As I mentioned earlier, that is not a configuration I have tested either Snort or Suricata with, so I'm not sure of the impact that has on some of the internal code of the custom blocking plugin used in Legacy Blocking mode operation.

When Suricata starts up it will query all the firewall interfaces and ask for the currently assigned IP address of each interface. It stores those IP addresses (the /32 address, not the subnet) in a special internal pass list table. This code was added, I believe, about 4 years ago to help prevent blocking of the firewall interface IPs by Suricata and Snort. This was happening to users with DHCP-based WAN IP addresses in particular. So new code was added to scan the firewall interfaces at startup, and then launch a separate process thread that monitored future interface IP changes by subscribing to the FreeBSD kernel route table messages. When a firewall interface IP changes, the Suricata custom blocking plugin used in Legacy Blocking mode receives a notice of the IP address change. It then modifies the content of the internal pass list.

I'm beginning to wonder if this process is getting tripped up by the bridge members you may have defined for transparent operation. That's why I would like to see the suricata.log file if you still have one from an earlier Legacy Blocking mode run. The file is overwritten each time Suricata starts up on an interface, so you would need to configure Legacy Blocking mode, start the interface, then copy off the suricata.log file (or its contents) prior to another shutdown/startup sequence. I'm wanting to see the lines near the top of the log where the custom blocking plugin logs the interface name and current IP address of each configured firewall interface. The lines of text look similar to this:

alert-pf -> adding firewall interface em1 IPv4 address 1.2.3.4 to automatic interface IP Pass List.

Of course in your case, the interface name and IPv4 address will be different. But please don't scrub the IP if possible as I need to see what exact value is getting recorded. This might be what is causing some of your issues with blocking in Legacy Mode operation. The code for putting the firewall interface IPs in the internal pass list may be creating a too-broad range of whitelisted IP addresses.

everfree

My suricata.log is

alert-pf -> Pass List /usr/local/etc/suricata/suricata_35030_ix0/passlist parsed: 158 IP addresses loaded.

passlist parsed 158 IP is

8.8.4.4/32
8.8.8.8/32
59.120.208.208/32
59.120.235.235/32
59.120.242.111/32
59.125.1.114/32
59.125.1.115/32
59.125.14.1/32
59.125.86.119/32
59.126.9.231/32
59.126.182.150/32
61.56.0.0/20
61.56.4.0/24
61.56.8.0/21
61.57.32.0/19
61.57.54.0/23
61.57.56.0/23
61.60.20.0/24
61.60.21.0/24
61.60.22.0/24
61.60.29.0/24
61.60.32.0/23
61.60.34.0/24
61.60.92.0/24
61.60.93.0/24
61.60.94.0/23
61.60.96.0/24
61.60.97.0/24
61.60.122.0/23
61.67.64.0/19
61.67.93.0/24
61.67.94.0/24
61.67.95.0/24
61.221.80.11/32
66.249.64.0/19
117.56.0.0/16
117.56.6.0/24
117.56.30.0/24
117.56.79.0/24
117.56.104.0/23
117.56.106.0/23
117.56.108.0/24
117.56.110.0/24
117.56.111.0/24
117.56.112.0/24
117.56.113.0/24
117.56.118.0/23
117.56.152.0/23
117.56.161.0/24
117.56.238.0/24
117.56.239.0/24
117.56.244.0/23
118.163.8.90/32
118.163.209.137/32
120.96.0.0/11
124.199.64.0/19
124.199.96.0/20
124.199.108.0/23
124.199.110.0/23
125.227.186.86/32
127.0.0.1/32
134.208.0.0/16
140.109.0.0/16
140.110.0.0/15
140.110.141.23/32
140.111.64.0/18
140.112.0.0/12
140.112.57.111/32
140.112.65.202/32
140.112.65.206/32
140.113.0.0/12
140.114.0.0/12
140.115.0.0/12
140.116.0.0/12
140.116.221.36/32
140.116.221.37/32
140.116.221.38/32
140.116.221.39/32
140.117.0.0/16
140.119.0.0/16
140.128.0.0/13
140.136.0.0/15
140.138.0.0/16
163.13.0.0/16
163.14.0.0/15
163.15.0.0/16
163.16.0.0/13
163.17.0.0/19
163.18.0.0/16
163.19.0.0/16
163.20.0.0/16
163.21.0.0/19
163.22.0.0/16
163.22.0.0/19
163.23.0.0/16
163.24.0.0/14
163.25.0.0/18
163.26.0.0/16
163.27.0.0/16
163.28.0.0/16
163.29.0.0/16
163.30.0.0/15
163.32.0.0/16
168.95.1.1/32
168.95.192.1/32
175.183.83.82/32
175.183.91.163/32
192.192.0.0/16
202.169.169.32/32
203.64.0.0/16
203.68.0.0/16
203.71.0.0/16
203.72.0.0/16
203.74.121.45/32
210.59.0.0/17
210.60.0.0/16
210.61.91.43/32
210.61.91.44/32
210.62.64.0/19
210.62.224.0/20
210.62.240.0/21
210.62.247.0/24
210.67.248.0/21
210.69.0.0/16
210.69.61.0/24
210.70.0.0/16
210.70.125.132/32
210.71.0.0/17
210.71.213.29/32
210.240.0.0/16
210.241.0.0/17
210.241.57.0/24
210.241.90.0/24
210.241.91.0/24
210.241.96.0/24
210.241.110.0/24
210.243.0.0/18
210.243.49.81/32
211.20.66.150/32
211.21.2.211/32
211.21.204.80/32
211.21.204.82/32
211.75.165.114/32
211.75.194.79/32
211.79.113.33/32
211.79.128.0/19
211.79.136.0/24
211.79.137.0/24
211.79.153.0/24
211.79.154.0/24
211.79.160.0/19
211.79.163.0/24
211.79.184.0/23
211.79.189.0/24
220.132.30.215/32
220.134.59.158/32
223.200.0.0/16
::1/128

bmeeks

Yes, I understand that you have your own pass list, but the Suricata binary code also creates its own secondary list composed of the firewall interface IP addresses. The assumed setup of a firewall for the Suricata blocking plugin is one with multiple interfaces and each interface is a different network subnet. So say a LAN and a WAN interface, but two different subnets on each and the firewall routes traffic between them based on IP routing rules. So this secondary hidden pass list I'm talking about in my post above asks the FreeBSD kernel for the current IP addresses assigned to the firewall interfaces and stores those in an internal pass list that you can't see. However, when it does this asking of the kernel for the interface IPs, it logs the information received in the suricata.log file. That's the information I want to see from your setup. Your configuration is different because you stated you have a transparent firewall. That sort of breaks the assumptions present within the secondary pass list code. I want to see what the kernel is returning in terms of IP address info for your bridge member interfaces.

everfree

My configuration?? Setup??

I don't know what i can post it??

30/8/2019 -- 09:09:40 - <Notice> -- This is Suricata version 4.1.4 RELEASE
30/8/2019 -- 09:09:40 - <Info> -- CPUs/cores online: 88
30/8/2019 -- 09:09:40 - <Info> -- HTTP memcap: 2048108864
30/8/2019 -- 09:09:40 - <Notice> -- using flow hash instead of active packets
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> Creating automatic firewall interface IP address Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface ix0 IPv6 address fe80:0000:0000:0000:021b:21ff:fe94:dc94 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface ix0 IPv4 address 163.22.49.28 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface ix1 IPv6 address fe80:0000:0000:0000:021b:21ff:fe94:dc95 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface bge0 IPv6 address fe80:0000:0000:0000:f603:43ff:fe5c:88b4 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface bge0 IPv4 address 163.22.168.119 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address 0000:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address fe80:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> adding firewall interface lo0 IPv4 address 127.0.0.1 to automatic interface IP Pass List.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf output device (regular) initialized: block.log
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_35030_ix0/passlist parsed: 158 IP addresses loaded.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> Created firewall interface IP change monitor thread for auto-whitelisting of firewall interface IP addresses.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf -> Firewall interface IP address change notification monitoring thread started.
30/8/2019 -- 09:09:46 - <Info> -- alert-pf output initialized, pf-table=snort2c  block-ip=both  kill-state=on  block-drops-only=off
30/8/2019 -- 09:09:46 - <Info> -- fast output device (regular) initialized: alerts.log
30/8/2019 -- 09:09:46 - <Info> -- stats output device (regular) initialized: stats.log
30/8/2019 -- 09:09:46 - <Info> -- Syslog output initialized
30/8/2019 -- 09:09:54 - <Info> -- 2 rule files processed. 25809 rules successfully loaded, 0 rules failed
30/8/2019 -- 09:09:54 - <Info> -- Threshold config parsed: 4 rule(s) found
30/8/2019 -- 09:09:54 - <Info> -- 25809 signatures processed. 0 are IP-only rules, 12739 are inspecting packet payload, 15694 inspect application layer, 0 are decoder event only
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.autoit.ua' is checked but not set. Checked in 2019165 and 1 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.http.binary' is checked but not set. Checked in 2018748 and 8 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'is_proto_irc' is checked but not set. Checked in 2002029 and 6 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.http.javaclient.vulnerable' is checked but not set. Checked in 2013036 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.http.javaclient' is checked but not set. Checked in 2011544 and 3 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.gadu.loggedin' is checked but not set. Checked in 2807836 and 5 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.ELFDownload' is checked but not set. Checked in 2019896 and 1 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.DocVBAProject' is checked but not set. Checked in 2020170 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.MSSQL' is checked but not set. Checked in 2020569 and 1 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ETPRO.RTF' is checked but not set. Checked in 2020700 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.Terse.Pastebin' is checked but not set. Checked in 2813075 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.MCOFF' is checked but not set. Checked in 2022303 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.IE7.NoRef.NoCookie' is checked but not set. Checked in 2023671 and 3 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'min.gethttp' is checked but not set. Checked in 2023711 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.pdf.in.smtp.attachment' is checked but not set. Checked in 2826083 and 5 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.armwget' is checked but not set. Checked in 2024241 and 1 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.pdf.in.http' is checked but not set. Checked in 2826149 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.raiffeisenapk' is checked but not set. Checked in 2828074 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.HTA.Download' is checked but not set. Checked in 2816701 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ETPRO.certutilhttp' is checked but not set. Checked in 2833774 and 3 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.smb.binary' is checked but not set. Checked in 2027402 and 0 other sigs
30/8/2019 -- 09:09:54 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.Socks5.OnionReq' is checked but not set. Checked in 2027704 and 0 other sigs
30/8/2019 -- 09:10:19 - <Info> -- Using 1 live device(s).
30/8/2019 -- 09:10:19 - <Info> -- using interface ix0
30/8/2019 -- 09:10:19 - <Info> -- Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
30/8/2019 -- 09:10:19 - <Info> -- Set snaplen to 1518 for 'ix0'
30/8/2019 -- 09:10:46 - <Info> -- RunModeIdsPcapAutoFp initialised
30/8/2019 -- 09:10:46 - <Notice> -- all 89 packet processing threads, 2 management threads initialized, engine started.
30/8/2019 -- 09:10:46 - <Info> -- No packets with invalid checksum, assuming checksum offloading is NOT used

bmeeks

That's what I needed to see. ~~I see that the IPv6 addresses for the bridge interfaces are apparently getting set to all zeros~~. But the IPv4 stuff looks OK.

The only other thing I can imagine that might be happening is the Radix Tree code that checks to see if a given IP address (from an alerting packet) is within an IP range stored in the Pass List is getting confused by some of the large IP blocks you have whitelisted. It should not get confused, but perhaps it is.

edit: strike the part about IPv6 being all zeros. I missed seeing the ending "1" at the end when I first checked them out.

bmeeks

So what happens inside the custom blocking plugin code is that it added 8 additional IP addresses to the Pass List you provided. Those 8 addresses are the ones shown in the log you posted (the 163.22.49.28 and the others).

I wanted to see what actual values the code was getting from the FreeBSD kernel since you mentioned transparent mode operation (and that implies a bridge interface with bridge members). However, the values look reasonable.