I am trying to control ingest rate into Splunk Cloud. I have some firewalls that are very chatty. The firewalls themselves can only point to a single Syslog destination.  For security and compliance issues, I need to retain and store ALL logs for one year. We have an appliance that forwards to our SOC and it basically has unlimited storage. For reporting and alerting, I need to send most messages into Splunk Cloud. Logging is controlled by ACL and in the syslog messages, you see ACLs. Based on how my firewall is configured, there are a few ACLs that are chattier than others, for example, the implicit deny ACL is CONSTANTLY chatting. The only time I really need to see this ACL in Splunk logs, is when I am troubleshooting however the SOC wants to see this ACL all the time. The implicit deny rule accounts for about 30% of all syslog data generated. Ideally I when I write to disk on the Syslog-NG server, I would like to drop the implicit deny logs so that when the Universal Forwarder reads the log, it won't be sending that unneeded 30% overhead (the implicit deny rule accounts for about 20-50 gigs of ingest a day alone).  My initial log_path statement looks like the following:       log { source(s_udp514); filter(f_device); destination(d_socappliance); destination(d_disk); flags(final); };         I then tried 2 different log path statements to try and separate the traffic so that I can apply the message drop filter:       filter f_device { ( host("192.168.1.1") or host("fqdn.device.com") ) }; filter f_device_msgdrop { ( not match("aclID=0" value(MESSAGE)); ) }; log { source(s_udp514); filter(f_device); destination(d_socappliance); flags(final); }; log { source(s_udp514); filter(f_device);filter(f_device_msgdrop); destination(d_disk); flags(final); };         aclID=0 is the ACL ID of the implicit deny rule. The concept here is that if the string "aclID=0" exists in the syslog message, I don't want to write it to disk and therefore the Universal Forwarder never sees in in the log file and it doesn't get sent to the cloud.  When I use the method above, I end up disabling logging to disk. I haven't verified if logging to the SOC appliance stops as well. Any thoughts on how to tackle this?  ... View more

Hey all, I am in the process of migrating from a Windows Heavy Forwarder to a Linux Heavy Forwarder for Splunk Cloud. Part of this exercise involves migrating the Splunk DB Connect App from the Windows HF Box to the new Red Hat 8.4 HF box. Quick Details: Splunk DBConnect 3.6.0 DBConnect App Host Red Hat Linux 8.4 ga OpenJDK(Coretto) 11.0.2 LTS MS SQL Server Windows Server 2016 Standard (1607) MS SQL 2014 (12.0.4522.0) Registry is modified to allow TLS 1.1 and 1.2 under Schannel (via IISCrypto Tool) Registry is also modified to allow strong SChannel .Net configuration. This was mentioned to be necessary for SQL Server 2019, but I figured it might apply to 2014 as well (https://learn.mediasite.com/course/enabling-tls-1-2/lessons/sql-server-configuration/) I basically duplicated the configuration from the original Windows Server that ran DBConnect App. I brought over the same connection information as well as the same identity information. I've validated that the identity information is correct. I am getting the following error:     Database connection server.domain.com is invalid. The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "Certificates do not conform to algorithm constraints".     This seems to imply that there is some sort of certificate negotiation error. I have browsed through the DBConnect documentation but nothing inside there seems to help. I noticed a few different keystores around the db connect app and I tried messing with a few of them, but without luck. Currently in the "keystore" folder, I have loaded a domain PKI cut/issued cert/key pair and the domain PKI CA chain. None of those seem to make any difference. My basic connection string looks like the following in the edit url box:     jdbc:sqlserver://server.domain.com:1433;databaseName=Splunk;selectMethod=cursor;encrypt=true     I've tried various differentiations of this as well like:     jdbc:sqlserver://server.domain.com:1433;databaseName=Splunk;selectMethod=cursor;encrypt=true;trustStore=/opt/splunk/etc/apps/splunk_app_db_connect/keystore/default.jks;trustStorePassword=password     I wasn't sure how to configure the JRE installation path and I also wasn't too positive on where it was located in the Red Hat 8.4 instance. I did some tracking and I think it's loaded here:     /usr/lib/jvm/java-11-openjdk-11.0.12.0.7-0.el8_4.x86_64/     I mainly did that because it appears like JAVA_HOME wasn't set in the OS. I could have set it but I figured it would take out any potentially issues if I just pointed it directly at the folder. I haven't had much luck. I loaded up wireshark and confirmed I could see the connection and I do see the inbound 1433 connection from the heavy forwarder. I do see the active connection being made, but because it's over 1433 Wireshark isn't showing any TLS negotiation. I am not sure if that's an issue or not. I am not sure where else to go from here. Does anyone have any thoughts? ... View more