Suricata Not Blocking legacy mode

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.

everfree

WAN 163.22.49.28
LAN none
MGMT 163.22.168.119

WAN bridge LAN is transparent mode. Suricata run WAN interface.

bmeeks

The only thing to do at this point would be to compile a special debug version of the Suricata binary, copy your Pass List IPs (all 158 of them) into the configuration, and then generate some packets having the SRC/DST IP addresses you posted earlier that are not blocking. It would take manually stepping through the binary code using the gdb debugger package to see what's really going on.

bmeeks

It will take me some time to compile the debug binary and set up the necessary debugging environment. Give me a few days to set this up and test. I will see if there is a bug in the code someplace. It could be in my custom blocking plugin, or it could be within the Radix Tree code that comes from Suricata upstream.

I will post back what I can find out, but it will be several days.

bmeeks

In the meantime, you might find that Inline IPS mode on the WAN interface will work well for you. You can implement your "Pass List" by using PASS rules in the Custom Rules category available on the RULES tab. I posted a link earlier to the Suricata documentation on using PASS rules.

everfree

I test Inline mode 3 years ago, i use intel ix0 nic, run it, system crash finally. 3 years ago, i use name(ntct) and discuss with you. Finally I select use Legacy Block Mode, and it works stablely. My Firewall has 2-3G bps traffic Realtime, and 800,000 states. 172 elementary and junior high schools traffic pass through this firewall.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

I test Inline mode 3 years ago, i use intel ix0 nic, run it, system crash finally. 3 years ago, i use name(ntct) and discuss with you. Finally I select use Legacy Block Mode, and it works stablely. My Firewall has 2-3G bps traffic Realtime, and 800,000 states. 172 elementary and junior high schools traffic pass through this firewall.

Inline IPS Mode is picky as it depends on the NIC driver adequately supporting the FreeBSD netmap driver. A user created a tutorial for tuning some NIC parameters to improve netmap performance. Here is a link to the Sticky Post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces. Even though the material primarily talks about em and igb drivers, some of the parameters are likely applicable to the ix driver as well.

Suricata 5.x, when it comes out, will have a rewritten netmap driver interface. That code has been rewritten by the upstream Suricata developer team. Maybe it will perform better with Inline IPS Mode..

I will attempt to reproduce and debug the issue you are having with Legacy Mode Blocking and Pass Lists.

bmeeks

@everfree:
I was able to compile a debug version of the Suricata binary and test for your issue in a VMware virtual machine. Unfortunately, I have thus far been unable to reproduce your problem. Here are the steps I used while attempting to replicate your setup along with the results of my testing.

Installed Suricata in Legacy Blocking Mode on the WAN interface of a VMware virtual machine. The WAN interface of this VM had the IP address 192.168.10.21 (an IP within my private LAN). This is a pfSense-2.5-DEVEL snapshot virtual machine.
I copied and pasted your Pass List from one of your earlier posts (the one containing 158 entries) into the Suricata configuration. I assigned that Pass List to the WAN Suricata interface on the test virtual machine.
I created the following custom rule within Suricata to test the alerting and blocking of traffic from two of the IP addresses that did not block for you (158.85.63.185 and 4.16.74.232). I used this simple rule so that any traffic sourced from either of those two IP addresses would trigger the alert and subsequent block.

Custom Rule:

alert ip [158.85.63.185, 4.16.74.232] any -> $HOME_NET any (msg:"Test rule triggered"; reference:url,doc.emergingthreats.net/bin/view/Main/CompromisedHosts; classtype:misc-attack; sid:2500000; rev:5175; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag COMPROMISED, signature_severity Major, created_at 2011_04_28, updated_at 2019_08_31;)

I fired up my Kali Linux "blackhat" virtual machine and used nmap to scan the target victim virtual machine (the one at 192.168.10.21). I used the "source address spoof" option in nmap to make my traffic appear to come from one of the two IP addresses that did not block for you. Here are the two nmap commands I used:

nmap -e eth0 -S 158.85.63.185 192.168.10.21
nmap -e eth0 -S 4.16.74.232 192.168.10.21

Those commands, when executed, resulted in these alerts on the target virtual machine (there is a lag of a few seconds between the first alert and the block in each case because I was manually stepping through the code in the debugger one line per step):

SuricataBlockTest_158.85.63.185_alerts.png

SuricataBlockTest_4.16.74.232_alerts.png

Those alerts then also resulted in these blocks (note that I cleared out all previous alerts and blocks when executing each test, so the screenshots are from two separate test runs: one with each IP address):

SuricataBlockTest_158.85.63.185_blocks.png

SuricataBlockTest_4.16.74.232_blocks.png

So as you can see above, the IP addresses that failed for you worked as expected in my testing. At this point I'm not sure what else I can try. Perhaps you can repeat my tests with your own Kali Linux virtual machine and see if you get the same result. You can try with my custom rule. I chose the custom rule route because I don't have the software necessary to generate an actual malware signature such as would be required to trigger the ET MALWARE rule you have in your screenshots earlier in this thread. However, which particular rule triggers should not matter when it comes to blocking. The blocking code works only with the packet IP addresses (either SRC, DST or BOTH as configured on the INTERFACE SETTINGS tab).

everfree

Block Both

bmeeks

@everfree :
I replicated a bridge setup that I think is like yours and I still could not reproduce your issue using the previous two IP addresses I tested with (158.85.63.185 and 4.16.74.232).

On your live firewall, have you actually checked the snort2c table to verify if the IP addresses that should be blocked are in fact missing from there as well? You check this under DIAGNOSTICS > TABLES and choosing snort2c as the table to display.

I agree that in your screen capture above, the "non-highlighted" IP addresses should indeed have been blocked, but apparently they were not. Or at least the PHP code in the GUI thinks they are not and thus is not showing the red X beside them.

I really have no idea what could be happening. Your firewall has a lot of traffic if your realtime load is 2-3 Gbps. I'm beginning to wonder if it is a loading issue. I have not been able to reproduce your problem in my test setup, but I cannot simulate that level of load in my test lab. Suricata being a multithreaded application makes debugging more difficult. There is also a possibility that the internal signal flow within the Suricata binary is not working correctly under load. There are two separate modules at work. One is stock from upstream and that module does the logging (writes the alerts to a specified log file). The other module is a custom output plugin I wrote that is supposed to get a copy of every alerting packet. Maybe that is not always happening under heavy load. Maybe the logging module gets the packet but my blocking module (the custom output plugin) does not get a copy of every single packet and thus misses the opportunity to block the traffic. Just theorizing here on possibilities. I will keep looking into the binary code to see if I spot someplace a problem like you are experiencing could creep in.

everfree

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

The patch *.diff file is here: https://github.com/pfsense/FreeBSD-ports/blob/devel/security/suricata/files/patch-alert-pf.difflink text.

If you want to examine the final patched source code, download a copy of the Suricata binary source tree version 4.1.4 from here. Untar that archive into an empty directory, then download the patch-alert-pf.diff file linked above and apply the patch to the source code tree. After doing all that, the source for the custom blocking plugin will be in the src/alert-pf.c and src/alert-pf.h files.

I've examined the code in the custom blocking plugin, and I have yet to find a way for the problem you describe to manifest itself. With me using your exact Pass List values, that should have reproduced the problem if it was something directly within the custom module. The fact it did not leads me to theorize it might be a load issue. Perhaps, under heavy load, my custom blocking plugin is not really seeing all the traffic. The alert log is taken directly from Suricata's alert-fast log module's output. So it would be theoretically possible for an alert to get logged but no block happen if the logging module saw the alert but my custom blocking plugin did not.

bmeeks

@everfree said in Suricata Not Blocking legacy mode:

where is the code about the custom output plugin??

I don't think it is a loading issue, because I can use it before.

But there have also been quite a number of changes within other parts of the Suricata binary over the last few years upstream that are not directly part of the custom blocking plugin used on pfSense. This makes it hard to nail down what might be the culprit; especially when the problem is not reproducible in a test environment.

everfree

This post is deleted!