@justme2 said in Suricata Pass Lists and Alias (URL/URL Table): Fair enough, sounds good. Thanks! I have it working in a new Suricata package for 23.01 and 2.7 CE Devel. This feature will be in the next update of Suricata that shows up for 23.01 pfSense Plus and 2.7 CE snapshot users. The package version will be 6.0.10_3. Here are some screenshots showing the new feature in action. Defined the URL Table alias under FIREWALL > ALIASES > URLs: [image: 1677348113605-firewall_alias_url_table.png] Assigned the URL Table alias to a custom Pass List on the PASS LISTS tab: [image: 1677348193358-pass_list_url_table_alias.png] Assigned the custom Pass List to the LAN interface in Suricata under INTERFACE SETTINGS: [image: 1677348230198-custom_pass_list_assigned.png] Here is the content of the custom Pass List when using View List on the INTERFACE SETTINGS tab for the LAN: [image: 1677348270718-custom_pass_list_content.png] And here is the suricata.log startup info for the LAN interface showing the custom blocking plugin read and processed the new "IP_Zoom" table alias: [image: 1677348329520-interface_suricata_log.png] Looking under DIAGNOSTICS > TABLES shows there are 3525 entries in this URL Table: [image: 1677348530162-diagnostics_tables_ip_zoom.png]

@bmeeks Restarted the PfSense and now the rules are presented in /usr/local/share/suricata/rules/ and i activated them in the GUI Everything is working fine, thank you for the help.

I will repeat here for clarity something I've mentioned in some other Suricata posts. The Suricata package consists of two unique and separate components. One is a GUI front-end written in PHP. That GUI is what you interact with. It is used to store and manage configuration information for the Suricata interfaces. When you click Save after making a configuration change, the GUI PHP code consolidates all the config parameters and writes them to the suricata.yaml file for the interface. The other piece of the package is the Suricata executable binary that runs as a service. This piece comes from the upstream Suricata developers. That binary is distributed to run on my different operating systems, but it is purely a command-line interface that uses a combination of the suricata.yaml config file and arguments passed on the command line to control its operation. The GUI part of Suricata on pfSense just generates that YAML file and then starts the binary piece with the appropriate command-line arguments. I mention this as a lot of folks seem to misunderstand the distinction between the GUI part they see and binary part they do not. But the binary is where all the real work happens.

@steveits posted there first, before i found out how to check the space, but couldn't delete it afterwards

@bmeeks Thanks for the input. I like having the additional rules, which don't seem to affect Suricata at all other than initially building the yaml files, but I know you are correct in finding a better way to optimize my rules. I'll have to go through and audit the ruleset vs what I have in the SID management. I basically have a SID drop file and SID disable, with default enable on the rulesets. Here are the SID drop/disable rules for WAN. I have similar SID files for 5 other interfaces that I manage/monitor with Suricata separately. I'm sure if I go through and find what rules I need on WAN, then reduce the rules even more for what I have on the internal interfaces, it would be a lot better. I won't need some of the WAN rules on internal interfaces, so only would then need rules appropriate for local interface to local interface, since the WAN rule will get anything in/outbound, if I'm thinking about it correctly. So I'll focus on that first. I'm not sure really where the memory usage is the highest when building the yaml files. Does the bulk of the memory usage come from loading the various rules, and then more memory is used when adding in the SID management files? If I know how the memory is consumed, I can try and optimize focusing on that, too. Here is the WAN disable SID: # WAN Disable Ruleset # ET Pro Rules etpro-chat,etpro-dns,etpro-games,etpro-icmp,etpro-icmp_info,etpro-inappropriate,etpro-info,etpro-p2p etpro-policy,etpro-tor # SNORT Rules snort_app-detect,snort_chat,snort_content-replace,snort_dns,snort_icmp-info,snort_icmp,snort_info snort_multimedia,snort_p2p,snort_policy,snort_x11 # Individual Disabled Ruleset # FIOS Guide 1:2840787 # ETPRO HUNTING Request for config.json # Suricata Stream 1:2210008 # SURICATA STREAM 3way handshake SYN resend different seq on SYN recv 1:2210016 # SURICATA STREAM CLOSEWAIT FIN out of window 1:2210029 # SURICATA STREAM ESTABLISHED invalid ack 1:2210038 # SURICATA STREAM FIN out of window 1:2210042 # SURICATA STREAM TIMEWAIT ACK with wrong seq 1:2210044 # SURICATA STREAM Packet with invalid timestamp 1:2210045 # SURICATA STREAM Packet with invalid ack 1:2210050 # SURICATA STREAM reassembly overlap with different data 1:2210054 # SURICATA STREAM excessive retransmissions # Breaks webpage/NEST 1:2221010 # SURICATA HTTP unable to match response to request # Breaks NEST 1:2018383 # ET EXPLOIT Possible OpenSSL HeartBleed Large HeartBeat Response from Common SSL Port (Outbound from Client) # Generated from LTE_Extender 1:2221045 # SURICATA HTTP Unexpected Request body # Weatherflow 1:2229001 # SURICATA MQTT PUBLISH not seen before PUBACK/PUBREL/PUBREC/PUBCOMP # Noisy / Misc 1:2023883 # ET DNS Query to a *.top domain - Likely Hostile 1:2027390 # ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent 1:2027757 # ET DNS Query for .to TLD 1:2027758 # ET DNS Query for .cc TLD 1:2200036 # SURICATA TCP option invalid length 1:2200070 # SURICATA FRAG IPv4 Fragmentation overlap 1:2200073 # SURICATA IPv4 invalid checksum 1:2200075 # SURICATA UDPv4 invalid checksum 1:2200076 # SURICATA ICMPv4 invalid checksum 1:2210002 # SURICATA STREAM 3way handshake right seq wrong ack evasion 1:2210004 # SURICATA STREAM 3way handshake SYNACK resend with different ack 1:2210010 # SURICATA STREAM 3way handshake wrong seq wrong ack 1:2210015 # SURICATA STREAM CLOSEWAIT ACK out of window 1:2210020 # SURICATA STREAM ESTABLISHED packet out of window 1:2210023 # SURICATA STREAM ESTABLISHED SYNACK resend with different ACK 1:2210024 # SURICATA STREAM ESTABLISHED SYNACK resend with different seq 1:2210026 # SURICATA STREAM ESTABLISHED SYN resend 1:2210030 # SURICATA STREAM FIN invalid ack 1:2210035 # SURICATA STREAM FIN2 FIN with wrong seq 1:2210036 # SURICATA STREAM FIN2 invalid ack 1:2210046 # SURICATA STREAM SHUTDOWN RST invalid ack 1:2221014 # SURICATA HTTP missing Host header 1:2221017 # SURICATA HTTP invalid response field folding 1:2221021 # SURICATA HTTP response header invalid 1:2224003 # SURICATA IKEv2 weak cryptographic parameters (PRF) 1:2224004 # SURICATA IKEv2 weak cryptographic parameters (Auth) 1:2224005 # SURICATA IKEv2 weak cryptographic parameters (Diffie-Hellman) 1:2229002 # SURICATA MQTT SUBSCRIBE not seen before SUBACK 1:2229005 # SURICATA MQTT message seen before CONNECT/CONNACK completion 1:2230003 # SURICATA TLS invalid handshake message 1:2230010 # SURICATA TLS invalid record/traffic 1:2260000 # SURICATA Applayer Mismatch protocol both directions 1:2260002 # SURICATA Applayer Detect protocol only one direction Here is the WAN Drop Sid: # WAN Drop Ruleset # Snort GPLv2 Community Rules Drop GPLv2_community # Feodo Tracker Botnet C2 Rules feodotracker # Abuse.ch SSL Blacklist Rules sslblacklist_tls_cert # ET Pro Rules etpro-activex,etpro-adware_pup,etpro-attack_response,etpro-botcc,etpro-ciarmy,etpro-coinminer etpro-compromised,etpro-current_events,etpro-dos,etpro-drop,etpro-dshield etpro-exploit,etpro-exploit_kit,etpro-ftp,etpro-hunting,etpro-imap,etpro-ja3,etpro-malware,etpro-misc etpro-mobile_malware,etpro-netbios,etpro-phishing,etpro-pop3,etpro-rpc etpro-scan,etpro-shellcode,etpro-smtp,etpro-sql,etpro-telnet,etpro-tftp,etpro-threatview_CS_c2 etpro-trojan,etpro-user_agents,etpro-web,etpro-worm # Snort Ruleset snort_attack-response,snort_backdoor,snort_bad-traffic,snort_blacklist,snort_botnet-cnc,snort_browser snort_ddos,snort_deleted,snort_dos,snort_experimental,snort_exploit-kit,snort_file,snort_finger snort_ftp,snort_indicator,snort_local,snort_malware,snort_misc,snort_mysql,snort_netbios,snort_os snort_other-ida,snort_phishing-spam,snort_pop,snort_protocol,snort_pua,snort_rpc,snort_rservices snort_scan,snort_server,snort_shellcode,snort_smtp,snort_snmp,snort_specific-threats snort_spyware-put,snort_sql,snort_telnet,snort_tftp,snort_virus,snort_voip,snort_web # Individual Ruleset 1:2210008 # SURICATA STREAM 3way handshake SYNACK resend with different ack 1:2210026 # SURICATA STREAM ESTABLISHED SYN resend

@manilx Fixed by switching to snort 2.9 ruleset. Was using 3.x one by error.

@stewart said in TLS/Applayer rules usefullness: As a company that we had transition from direct RDP to VPN Ouch! RDP directly exposed to the Internet gives me nightmares .

It's a regression bug, but not PHP. Here is the open Redmine Issue: https://redmine.pfsense.org/issues/13958. This is going to take some time to fix (if it is even fixable) in FreeBSD 14. Your only option for now is to remove Snort from your SG-3100. It will retain your configuration parameters in config.xml, and when you reinstall Snort it will restore the previous settings.

PHP loves to cache files for performance, so that means when you run a package "upgrade in place" versus a complete uninstall and then reinstall, an older version of files can get used from the cache. The snort.inc is a central include file that all of the PHP source files in Snort reference. So it gets cached. If you had deleted (removed) the Snort package and then installed it again, you would not see the error as during the uninstall the file is removed from the PHP cache.

@sstatjm reboot is done so will see if it still show up in there again.

You say "restart Snort". When you go to the INTERFACES tab in Snort when the alerts tab is blank, is Snort showing as running or not (green triangle or red "X")? If not, then you need to look in the pfSense system log and determine why it stopped. Something should be logged there. If it is showing as running (with the green triangle instead of a red "X"), then something else is at play.

SteveITS , >>bmeeks Thanks for the reply. As you indicated, I've set the log directory size limit and the error message no longer appears! I will continue to use this device, thank you both.

This has been fixed in the upcoming Snort 4.1.6_6 package which should show up in the new pfSense Plus 23.01 RC and the pfSense 2.7.0 CE branches.

@bmeeks Just in case anyone following this cares :), I am now only running port scan rules on my WAN interface, and leaving everything else in my LAN interface. This was easy to do because I run everything from SID files, so I just downloaded my custom Enable and Disable files, copied them as "EnableWAN" and "DisableWAN," whittled down the contents from each that pertained to "emerging-scan"...configured them in the List Assignments area, clicked the Rebuild boxes, hit Save, and I was off to the races. Only extra thing I had to do was in the "WAN Categories" tab - I had to hit "Unselect All" and "Save" to disable the (now-manually-checked remnant) rulesets that had been previously enabled by the old SID files. The one category in my "EnableWAN" file stayed enabled with the special little "A" icon. Everything really is much more "sane" now - I am getting the port scanning protection I want on the WAN; I have more sane "Blocks"; and I have better Alert information logs for the LAN. All that, and using much less RAM (usually was running at 31-35%; now at 21-22%) Thanks again!

@troutpocket said in Suricata unable to initialize: @bmeeks That's wild... because I only ever installed it via the WebUI! I have ripped it out again and rebooted the router again and installed it (from the WebUI) again... and now it starts up. False alarm. I guess I have a different problem on my hands. Yeah, that ipfw error is definitely not from a standard package installation. Or else someone manually edited the suricata.yaml file for the interface and uncommented that IPS divert option (or copied over one not from a normal pfSense installation that had that option enabled).

@michmoor FIXED. What i did? Unselect the option to send to syslog. Clicked Save. Then i received the following message EVE Output to syslog requires Suricata alerts to be copied to the system log, so 'Send Alerts to System Log' has been auto-enabled. Tested again...Works. Alerts received in the logging server as well as email notification.

@cybersec_s said in Colbaltstrike Alert on Suricata: @bmeeks whew! Thank you for clarifying this The suricata.log file is where Suricata writes its startup messages, and any pertinent errors that occur. That log file is recreated each time Suricata is started. That is not where alerts and blocks are logged, though. Those are written to individual files located in subdirectories under /var/log/suricata/ for each configured interface. But it is far easier to view the alerts and blocks using the GUI tools available on the ALERTS and BLOCKS tab in Suricata.