Suricata Not Blocking legacy mode
-
Re: [Hello BMeeks](good morning I have performed all of the above)
Re: Suricata Not Blocking legacy mode
I am using Pfsense - 2.4.4-RELEASE P10 -
I just tested Suricata_4.1.4_5 in a virtual machine running pfSense-2.4.4_3 and I do not get the error you posted earlier in another thread. How did you install Suricata? Specifically, have you perhaps copied over or otherwise obtained a Suricata binary from some other place? Suricata on pfSense uses a custom-patched binary to provide the Legacy Blocking Mode operation. If you obtained a Suricata binary from any other place besides the normal Suricata package install process within the pfSense GUI, then that will be the root of your problem.
The error message you posted above indicates the
suricata
binary in/usr/local/bin
is not patched for Legacy Mode Blocking operation. I just verified that my patch is included in thesuricata
binary that gets installed with the pfSense GUI package. -
Here are some screenshots from my test virtual machine. Suricata is configured to run on the WAN interface and set to use Legacy Blocking Mode. I scanned the Suricata VM's WAN IP address from another Kali Linux virtual machine. The Emerging-Scan rules were enabled on the Suricata machine.
Here are the alerts recorded from an
nmap
scan from the Kali Linux VM. The IP of the Kali machine is 192.168.10.21, and the Suricata firewall IP is 192.168.10.124:And here is the resulting block of the Kali Linux machine's IP address:
I installed the Suricata package fresh on the test virtual machine this morning immediately after reading your post. The times are for the U.S. Eastern Time Zone (where I live).
-
You need to delete the Suricata package from your machine using the pfSense GUI. Next, open a shell command-line session and execute this command to wipe out any other binary you may have installed with your previous terminal actions:
rm -f /usr/local/bin/suricata
Then reinstall the Suricata package from the pfSense GUI under the SYSTEM > PACKAGE MANAGER menu item.
-
Hi Bill,
Sorry for the confusion regarding the binary package. I ended up installing
it from FreeBSD repository and it was the root cause of the missing alert-pf
message.It has been reinstalled now as you can see:
pfSense-pkg-suricata-4.1.4_5 pfSense package suricata
suricata-4.1.4_2 High Performance Network IDS, IPS and Security Monitoring engineThough I still see a problem when I try to block using legacy mode. Here are
the steps to reproduce it:- Configure suricata interface on WAN and check "Block Offenders" option
- Set it to legacy mode and save it.
- Edit recently created interface and in WAN rules, click on custom rules
- Paste the following rule:
drop tcp any any -> any any (msg:"facebook"; flow:from_client; content:"facebook"; sid:9150001; classtype:misc-activity; rev:1;)
After that I can see the alerts and it says offender IP address is blocked but
it's not. I've checked snort2c pf table and it's empty.Changing it to inline mode makes it to block offender IP address immediately.
Thanks!
-
@wesleyperes said in Suricata Not Blocking legacy mode:
Hi Bill,
Sorry for the confusion regarding the binary package. I ended up installing
it from FreeBSD repository and it was the root cause of the missing alert-pf
message.It has been reinstalled now as you can see:
pfSense-pkg-suricata-4.1.4_5 pfSense package suricata
suricata-4.1.4_2 High Performance Network IDS, IPS and Security Monitoring engineThough I still see a problem when I try to block using legacy mode. Here are
the steps to reproduce it:- Configure suricata interface on WAN and check "Block Offenders" option
- Set it to legacy mode and save it.
- Edit recently created interface and in WAN rules, click on custom rules
- Paste the following rule:
drop tcp any any -> any any (msg:"facebook"; flow:from_client; content:"facebook"; sid:9150001; classtype:misc-activity; rev:1;)
After that I can see the alerts and it says offender IP address is blocked but
it's not. I've checked snort2c pf table and it's empty.Changing it to inline mode makes it to block offender IP address immediately.
Thanks!
Installing the binary directly from FreeBSD is not the correct thing to do on pfSense. As I stated, pfSense uses a customized binary running a patch that provides the blocking capability.
The DROP action is typically associated with using Inline IPS Mode. Each time you change the blocking mode, you must restart Suricata on the interface. Blocking in Suricata works (both Legacy Mode and Inline). I've tested it in my own virtual machine with a fresh install. You are doing something wrong or else you have an actual configuration that is different from what you think you have.
-
@bmeeks said in Suricata Not Blocking legacy mode:
You are doing something wrong or else you have an actual configuration that is different from what you think you have.
The problem was that a custom rule was in drop in the legacy_mode, but have be reject, drop is only inline_mode.
Thanks Bill.
-
@wperes said in Suricata Not Blocking legacy mode:
@bmeeks said in Suricata Not Blocking legacy mode:
You are doing something wrong or else you have an actual configuration that is different from what you think you have.
The problem was that a custom rule was in drop in the legacy_mode, but have be reject, drop is only inline_mode.
Thanks Bill.
Actually, for Legacy Mode, the action verb should be ALERT. DROP will work when using the special Suricata option of "block on DROPS only" when Legacy Mode is enabled. However, you are correct that typically DROP and REJECT are associated with Inline IPS Mode.
-
@bmeeks said in Suricata Not Blocking legacy mode:
Here are some screenshots from my test virtual machine. Suricata is configured to run on the WAN interface and set to use Legacy Blocking Mode. I scanned the Suricata VM's WAN IP address from another Kali Linux virtual machine. The Emerging-Scan rules were enabled on the Suricata machine.
Here are the alerts recorded from an
nmap
scan from the Kali Linux VM. The IP of the Kali machine is 192.168.10.21, and the Suricata firewall IP is 192.168.10.124:And here is the resulting block of the Kali Linux machine's IP address:
I installed the Suricata package fresh on the test virtual machine this morning immediately after reading your post. The times are for the U.S. Eastern Time Zone (where I live).
Hi Bill,
You use ET-SCAN rules to test, it works. But when you select ET-MALWARE or ET-TROJAN, it's not working.
no ip can be blocked. because src ip (in passlist) to dst ip (not in passlist) can not be blocked. -
@everfree :
There is no difference in the Suricata binary code that is triggered because you select different rules. If the code blocks for one set of rules, it will block for another set of rules if those rules also properly trigger. Do you think Suricata examines which rule set you have enabled and then randomly decides not to block for one of them?If you are not getting blocks from a given rule (or rule category) then that rule is either not triggering, or if you are using Inline IPS Mode or Legacy Mode with "block DROPs only" enabled, the action keyword is something other than DROP.
Also understand that when using Inline IPS Mode the ALERTS tab display is different and the BLOCKED tab has no function at all. For Inline IPS Mode, rule alerts that have resulted in dropped traffic will be shown highlighted in red. The BLOCKED tab will be empty because that subsystem is not used with Inline IPS Mode operation.
Suricata's operation with regards to blocking traffic is quite different depending on which of the three operating modes are selected: 1) Legacy Mode; 2) Legacy Mode using block DROPs only; or 3) Inline IPS Mode. Based on all of the questions you have submitted thus far, it appears to me you are confusing the various operating modes and what will be displayed in terms of blocks or drops for each mode.
-
@bmeeks said in Suricata Not Blocking legacy mode:
Legacy Mode with "block DROPs only" enabled,
I sure that Legacy Mode with "block DROPs only" disabled
src 163.22.0.0/16 (in my passlist),dst 158.85.63.185 (not in my passlist)
-
@everfree said in Suricata Not Blocking legacy mode:
@bmeeks said in Suricata Not Blocking legacy mode:
Legacy Mode with "block DROPs only" enabled,
I sure that Legacy Mode with "block DROPs only" disabled
So if you have Legacy Mode disabled, then you have to use Inline IPS Mode. If you use Inline IPS Mode you must manually change rule actions to DROP for any "blocks" to happen. You can do that either via the icons on the ALERTS or RULES tabs, or you can use the features on the SID MGMT tab to change a specific GID:SID to DROP or you can change an entire category to DROP using SID MGMT features.
There are several Sticky Posts at the top of this forum that describe how the various Suricata blocking mode work and how to configure them.
Here is one link: https://forum.netgate.com/topic/119237/about-the-new-block-on-drops-only-option-in-suricata-4-0-0/12.
Here is how to use SID MGMT: https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata.
Here is one that describes Pass List operation: https://forum.netgate.com/topic/119238/about-pass-lists-in-suricata.
-
I use Legacy Mode block for 2 years, it works, i can't sure what version let the problem occurred.
I only say the version have bug, I hope you check by check, I have bad English, I don't know give you more details. Dst is not have any block icon in block mode, it's strange. I have two suricata IPS, it have the same problem. one is 2 years before, others is the new machine.
thanks.
Ming-Chang Cheng.
-
@everfree said in Suricata Not Blocking legacy mode:
I use Legacy Mode block for 2 years, it works, i can't sure what version let the problem occurred.
I only say the version have bug, I hope you check by check, I have bad English, I don't know give you more details. Dst is not have any block icon in block mode, it's strange. I have two suricata IPS, it have the same problem. one is 2 years before, others is the new machine.
thanks.
Ming-Chang Cheng.
Looking at your last screen capture, it appears to me that you have blocking set to SRC IP only. I say that because you have the red X "unblock" icon showing for Source IP addresses that are not in your large Pass List network (I recall you said 163.22.0.0/16 was in your Pass List). For all of the ET MALWARE and ET MOBILE_MALWARE rules I see in your screen capture, the SRC IP is in your Pass List, so no block. However, for one of the ET WEB_SERVER rules (the last one shown), the SRC IP was 202.166.50.169 and that IP is showing as currently blocked (it has the red X icon).
I will fire up my test virtual machine again and double-check that blocking of DST IP addresses works.
-
yes, 202.166.50.169 is like ET-SCAN, it's inbound direction rules, ET-Trojan is outbound direction rules, I very sure block mode i select block both , so i don't know why 158.85.63.185 and others dst is not blocked.
-
@everfree said in Suricata Not Blocking legacy mode:
yes, 202.166.50.169 is like ET-SCAN, it's inbound direction rules, ET-Trojan is outbound direction rules, I very sure block mode i select block both , so id don't know why 158.85.63.185 and others dst is not blocked.
Go to the LOGS VIEW tab and select the interface where you posted the screen captures from. I assume it is maybe your WAN interface. If not, use whatever interface the earlier posted screen capture is from.
Open the
suricata.log
file and find this line:20/8/2019 -- 21:54:37 - <Info> -- alert-pf output initialized, pf-table=snort2c block-ip=both kill-state=on block-drops-only=off
This will display the startup cofiguration of the custom alert-pf blocking plugin. Post back here with what it says. The line above is from my test virtual machine with Suricata installed on it.
-
I just got these blocks in my test virtual machine. Notice that it blocked the DST IP on the WAN. The IP shown happens to be the Link-Local IP, but it was the destination address of the packet that triggered the rule. I am in the U.S. Eastern Time Zone, so my dates and times are obviously different than yours (by an entire day almost).
and here is the BLOCKS tab showing that blocked destination IP address along with the source IP.
So from this I have to conclude the code is working as it should. There has to be something astray in your configuration that you are overlooking.
-
20/8/2019 -- 13:15:06 - <Info> -- alert-pf output initialized, pf-table=snort2c block-ip=both kill-state=on block-drops-only=off
-
@everfree said in Suricata Not Blocking legacy mode:
20/8/2019 -- 13:15:06 - <Info> -- alert-pf output initialized, pf-table=snort2c block-ip=both kill-state=on block-drops-only=off
Have you modified anything in your HOME_NET or EXTERNAL_NET variables? Have you checked for any duplicate Suricata processes? I would certainly first check for a duplicate process using this shell command:
ps -ax | grep suricata
You should see only a single running instance of Suricata for each configured interface. If you see any duplicate processes, you need to stop all Suricata processes in the GUI, open a command-line shell and repeat the above command to see if any Suricata process is still running. If you see one, kill it with this shell command:
kill -9 <pid>
where <pid> is the process ID of the remaining Suricata process. At this point I don't know what else to suggest. The Suricata code is working for me, and I installed it fresh on this VMware virtual machine this morning (it is now 10:12 PM in the evening here). As you can see in my screen shots, the blocking is working for both directions (source and destination IPs). There is nothing in Suricata that would change simply based on the rules category.
-
@bmeeks If i don't select any passlist, My IPS show the same screen.
-
@everfree said in Suricata Not Blocking legacy mode:
@bmeeks If i don't select any passlist, My IPS show the same screen.
Just making sure you realize that anytime you change the Pass List or the blocking mode, you must restart Suricata on that interface in order for the change to become effective. Suricata only reads its configuration at startup. It does not "live update" any configuration setting. The only "live update" it can do is reload the rules.
-
And just to be complete, my virtual machine just recorded these IPv4 DST IP blocks:
So it's not just IPv6 addresses that block, the IPv4 addresses are blocking as well. Since Legacy Mode puts the interface in promiscuous mode, it is seeing all of my local LAN traffic on the VM's WAN interface because the WAN of this virtual machine is connected to my LAN. -
when i remove my passlist, it show below...
-
@everfree said in Suricata Not Blocking legacy mode:
when i remove my passlist, it show below...
Then your Pass List is too broad. It is whitelisting more IP address space than you think. The default Pass List will include your WAN IP address (just the actual IP, not the whole subnet), your LAN subnet, your DNS server IPs (if defined on the firewall setup), your WAN gateway IP, any VPN addresses and any Virtual IP addresses.
You need to examine the actual contents of the Pass List you had assigned to see what's up. I suspect a subnet is defined too large and is thus adding a lot of extra unintended IP space to the Pass List. Click the View List button beside Pass List to see what addresses are in the default list, then assign your custom Pass List and click View List for it to see what's different.
I think your last screen shot proves what I said several posts earlier. Your configuration is not exactly how you believed it to be. In this case, I suspect your Pass List is overly broad and thus whitelisting a large chunk of IP space (and therefore you get no blocks on those IPs as is proper when an IP address is covered by a Pass List entry).
-
I modify my passlist it only
127.0.0.1/32 163.22.0.0/16 ::1/128
it still not works. -
@everfree said in Suricata Not Blocking legacy mode:
I modify my passlist it only
127.0.0.1/32 163.22.0.0/16 ::1/128
it still not works.Post the content of your Pass List. Assign it on the INTERFACE SETTINGS tab and then click the View List button. Paste the content of that modal dialog back here to the forum. Better yet, post the content of both the default list and your custom list so we can examine the differences.
Since it works when you set the Pass List to "default", that means the underlying binary code works fine. Something is incorrect within your custom Pass List. At least that is the best theory I have.
-
NTCT_HOME127.0.0.1/32 163.22.0.0/16 ::1/128
default
!127.0.0.1/32 !163.22.0.0/16 !::1/128
-
@everfree said in Suricata Not Blocking legacy mode:
NTCT_HOME127.0.0.1/32 163.22.0.0/16 ::1/128
default
!127.0.0.1/32 !163.22.0.0/16 !::1/128
Those values appear incorrect for the "default" Pass List. That appears to be the content of your EXTERNAL_NET variable perhaps and not the Pass List. The default Pass List would never contain the negation (!) symbol. However, the default definition of EXTERNAL_NET would contain the negation symbol.
The default Pass List should contain your WAN IP address with a /32 netmask, your WAN gateway IP with a /32 netmask, and the IP address or addresses of any DNS servers you have configured on the General Setup screen of pfSense.
-
So the next step what can i do??
The default Pass List should contain your WAN IP address with a /32 netmask, your WAN gateway IP with a /32 netmask, and the IP address or addresses of any DNS servers you have configured on the General Setup screen of pfSense.
the default list i uncheck WAN IP and gateway
-
@everfree said in Suricata Not Blocking legacy mode:
So the next step what can i do??
If what you posted is actually your Pass List (and default Pass List) content, then you have a seriously messed up
config.xml
file section for the Suricata package. Either that, or you posted the wrong information. -
@everfree said in Suricata Not Blocking legacy mode:
So the next step what can i do??
The default Pass List should contain your WAN IP address with a /32 netmask, your WAN gateway IP with a /32 netmask, and the IP address or addresses of any DNS servers you have configured on the General Setup screen of pfSense.
the default list i uncheck WAN IP and gateway
You really should not do that. In fact, there is seldom any reason to modify the default values of a Pass List. The only useful modification is to add additional address space to the list using the alias option at the bottom of the edit dialog. There is really no good reason to remove an IP from the default Pass List.
Change you Pass List back to "default" and don't bother it. Why would you want to Suricata to block your WAN gateway IP anyway? That would totally kill all connectivity for your box. Same thing with your DNS servers.
-
default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
-
@everfree said in Suricata Not Blocking legacy mode:
default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
If that is your PASS LIST, then it is completely wrong. Pass Lists should NEVER contain the negation symbol (that exclamation point means "not in this IP range"). So basically that list would tell Suricata to never block on any IP address unless it was within the range listed. In effect, with the ! negation symbol, your Pass List is backwards.
I really can't believe this is the content of your default Pass List. It looks instead to be the content of maybe your default EXTERNAL_NET list. Are you absolutely positive you are clicking the correct View List button immediately to the right of the Pass List drop-down selector?
-
@bmeeks said in Suricata Not Blocking legacy mode:
@everfree said in Suricata Not Blocking legacy mode:
default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
If that is your PASS LIST, then it is completely wrong. Pass Lists should NEVER contain the negation symbol (that exclamation point means "not in this IP range"). So basically that list would tell Suricata to never block on any IP address unless it was within the range listed. In effect, with the ! negation symbol, your Pass List is backwards.
I really can't believe this is the content of your default Pass List. It looks instead to be the content of maybe your default EXTERNAL_NET list. Are you absolutely positive you are clicking the correct View List button immediately to the right of the Pass List drop-down selector?
this is passlist default
8.8.4.4/32 8.8.8.8/32 127.0.0.1/32 163.22.49.26/32 163.22.49.28/32 163.22.168.0/24 168.95.1.1/32 168.95.192.1/32 ::1/128 fe80::21b:21ff:fe94:dc94/128 fe80::21b:21ff:fe94:dc95/128 fe80::f603:43ff:fe5c:88b4/128
this is External Net default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
my custom passlist 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.22.49.26/32 163.22.49.28/32 163.22.168.0/24 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 fe80::21b:21ff:fe94:dc94/128 fe80::21b:21ff:fe94:dc95/128 fe80::f603:43ff:fe5c:88b4/128
-
@everfree said in Suricata Not Blocking legacy mode:
@bmeeks said in Suricata Not Blocking legacy mode:
@everfree said in Suricata Not Blocking legacy mode:
default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
If that is your PASS LIST, then it is completely wrong. Pass Lists should NEVER contain the negation symbol (that exclamation point means "not in this IP range"). So basically that list would tell Suricata to never block on any IP address unless it was within the range listed. In effect, with the ! negation symbol, your Pass List is backwards.
I really can't believe this is the content of your default Pass List. It looks instead to be the content of maybe your default EXTERNAL_NET list. Are you absolutely positive you are clicking the correct View List button immediately to the right of the Pass List drop-down selector?
this is passlist default
8.8.4.4/32 8.8.8.8/32 127.0.0.1/32 163.22.49.26/32 163.22.49.28/32 163.22.168.0/24 168.95.1.1/32 168.95.192.1/32 ::1/128 fe80::21b:21ff:fe94:dc94/128 fe80::21b:21ff:fe94:dc95/128 fe80::f603:43ff:fe5c:88b4/128
this is External Net default
!8.8.4.4/32 !8.8.8.8/32 !127.0.0.1/32 !163.22.0.0/16 !163.22.49.26/32 !163.22.49.28/32 !163.22.168.0/24 !168.95.1.1/32 !168.95.192.1/32 !::1/128 !fe80::21b:21ff:fe94:dc94/128 !fe80::21b:21ff:fe94:dc95/128 !fe80::f603:43ff:fe5c:88b4/128
Those look correct, and you posted earlier a screen shot showing blocking working as it should when you selected the default Pass List. So unless that post was wrong, then I stand by what I said earlier. Your NTCT_HOME custom pass list is incorrect. Take my advice and just use the default pass list. Don't change it. Set Pass List to "default", save the change, then restart Suricata on the interface. Things should work then.
And looking at the content of your custom pass list, no wonder you are not getting blocks. You have entire swaths of the Internet on your pass list. An IP on a Pass List will never get blocked. You need to seriously cut down on that Pass List. At the very least you need to be changing some netmasks. Why would you need to whitelist so many network blocks? You have a very large Pass List in terms of IP address space that it is whitelisting.
-
My IPS is transparent mode firewall, I must use custom passlist. This is 3G realtime and 800000 session.
-
@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.
-
between the 2 years, I never meet this issue. do you have email? I send config to you.
-
@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 ???
-
between the 2 years, I only add whitelist to my custom passlist, and disable some FP rules.