@greenflash said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:

@bmeeks In my case the doubled interfaces bug was also fixed with 6.0.10_3
Thanks a lot for your work!

Glad you are all set. Thank you for the feedback.

Highly likely this is a false positive. I believe this rule is simply looking for DNS destinations, and as Conficker is now so old and most (if not all) of the C&C sites are gone and likely replaced by legit hosts/traffic these days, the usefulness of the rule can be questioned.

@bitslammer said in Can't Run Suricata 6.0.10_3:

@bmeeks Decided not to wait. Went the manual route and it worked fine with those edits. Thanks again.

Okay. The manual edit is fine. The updated code makes those checks in a different manner so that PHP is happy and does not complain. That's necessary because of the changes in PHP 8.1 as compared to the 7.4 used in older pfSense editions. The change in PHP behavior is why there are so many GUI code changes in 23.01 (and coming in 2.7 CE) and reports of little annoying bugs related to PHP errors.

@bmeeks That's great! Thx.

@bmeeks Thanks a lot!

@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:
Firewall_Alias_URL_Table.png

Assigned the URL Table alias to a custom Pass List on the PASS LISTS tab:
Pass_List_URL_Table_alias.png

Assigned the custom Pass List to the LAN interface in Suricata under INTERFACE SETTINGS:
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:
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:
Interface_suricata_log.png

Looking under DIAGNOSTICS > TABLES shows there are 3525 entries in this URL Table:
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.