To modify an app and change the index, it'll require changes (or verification) in a few others places as well. 1. You'll need an updated indexes.conf to make the index. 2. You'll need to update the inputs.conf to get/route data into the new index. 3. You'll need to check your Role to see how tightly index access is set, and add the index to the appropriate Role(s) if needed. Easiest way to check at the file level is to grep your app folder looking for the index name. An app is all text (.conf,) .js, and .py files after all. Good luck! ... View more

If I understand you, the data is being ingested and is going to the index (network?) you've defined in the input stanza. The data is also being source typed: the index contains source types: barracuda:system, barracuda:web, and barracuda:waf. Is that correct? If the above is correct, it means that the regex matches are successful at a base level. Looking a bit deeper at the Add-on's props.conf for the "barracuda:waf" source type, there are a number of additional fields: [barracuda_waf_extractions_1] REGEX = (WF)\s([A-Z]{4})\s(.+?)\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s(\d+)\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s(\d+)\s(DENY|LOG|WARNING)\s(NONE|LOCKED)\s\[.+?\]\s([A-Z]+)\s(.+?)\s(.+?)\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s(\d+) FORMAT = log_category::$1 vendor_severity::$2 signature::$3 src_ip::$4 src_port::$5 dest_ip::$6 dest_port::$7 vendor_action::$8 vendor_follow_up_action::$9 http_method::$10 url::$11 vendor_protocol::$12 proxy_ip::$13 proxy_port::$14 They were also kind enough to provide a data sample as a reference. You can find the example in: /Splunk_TA_barracuda_waf_adc/samples/barracuda_waf.sample If you search for the source type "barracuda:waf" in your index over the recent time period when data has been ingested, and the data populates on the Search view, do you see any of those fields on the left side list of fields? The ones I expect to be very common are "dest_ip", "dest_port", "src_ip", and "src_port". I cannot say how often to expect any other fields. Take a look at the sample data for that source type. Do there appear to be significant differences if you compare it to one of your events that's being ingested "live"? When I've seen mismatched Add-on parsing for a given data source in the past, it is usually down to product version differences. The Add-on might have been written for an earlier or later version of the barracuda product than the one you're using. As the Add-on doesn't contain any version info, you can always contact the writer for clarification as well. The last line of the readme file has an address to contact. If those fields are extracting properly, then there might not be any problem. You'd have to find a field that should've extracted from the source data that failed to, and review the regexes designed to capture that field. Grab an event from your index, clean it up a bit, grab the regex strings from the Add-ons, find an on-line regex tester, and do some quick checks! Note: I did this using the regex above with the sample data on regex101, and the resulting groupings were a match for the listed field values. ... View more

You're welcome! ... View more

Sorry, I missed the "day, time from events" portion of the question. I think "sbbadri" has the piece you're looking for. Good luck! ... View more

Can i suggest maintainers to get some better documentation? Yes, you can. On the page for the "New Juniper app produced by Juniper," there's a link to "Contact Developer" with their email address. Send them a note referencing the portion of the Splunk-made app docs you find the most compelling, and ask them to update the Details section of the app or provide a more detailed README file in the next release. ... View more

These: one and two older Answers posts cover the typical scenarios and provide regex samples on using a custom datetime.xml to extract the date from the file name. ... View more

Yes. File a support case, and ask for the workaround listed in SOLNESS-12077. ... View more

Fortunately, the status quo has changed in the last couple years! The PCI app is now designed to co-habitate with Splunk Enterprise Security on the same SH or SHC. As a bonus, that means ES and PCI will use the same data model accelerations when configured together. Check the PCI app Release Notes page for the compatibility with various ES versions. ... View more

Yes it can. However, I took a quick look at that app, and they've embedded index=sonicwall into about ~20 files, including dashboard .xml and .js files. Here are the two popular options: 1. Make your own copy of the app, customizing the various configs with your custom index name. It's all text files, so it's actually pretty quick. But, once you customize the app any automatic upgrades to the app will not work for you. In fact, if you auto-upgrade by accident, it'll break your customized app until you've gone back and fixed everything. 2. Create the 'sonicwall' index as they recommend, and write your data there. ... View more

Fundamentally, this is about how you'll manage add-ons when it comes to the ES app. There are a couple of important points around add-on management, the ES installer, and ES features that are confusing. Let's see if that can be cleared up a bit 🙂 1. ES Add-ons must be installed on the ES SH. True, and required. When you install Splunk Enterprise Security, the ES installer installs and enables the add-ons included in the ES package on the search head. When you upgrade, the installer does the same work all over again. It's not an intelligent installer, but simply does a version check and overwrite. 2. The ES SH can be a deployment client. True, but not always necessary. In all versions of the ES installer so far, the installer will force an upgrade of the included add-ons/TA's on the SH. Would you rather extract the add-ons/TA's, and place them on the Deployment Server (DS) to keep them in sync and centrally managed, or just use the ES installer to do the work? Each option has advantages and disadvantages in managing the upgrade processes. If your company wants to centrally manage a number of home-grown apps (domain and company specific knowledge) that reside on the ES SH, configuring the ES SH as a deployment client might become a necessity. Also, in some future release, the ES installer might stop providing the add-ons/TA's, in which case managing them with DS for the SH will be necessary. 3. A feature of the ES 4.x version is the ability to create a "Splunk_TA_ForIndexers," which can also be pushed back to the DS if the ES SH is a deployment client. True, but not very useful for most deployments. The "Splunk_TA_ForIndexers" is a roll-up all of the defined indexes and props/transforms spread across all add-ons/TA's on the ES SH placed into one app. It is (in my opinion) a better tool to validate what needs to be managed on the Indexers, as it will provide a handy list of index names that you'll need to account for. It doesn't replace the need for a deployment-wide, centrally managed indexes.conf. The "Splunk_TA_ForIndexers" could replace the need for centrally-managed add-ons/TA's that provide index-time props/transforms. But, the "Splunk_TA_ForIndexers" can only analyze what's installed on the ES SH. 4. The installation of Enterprise Security on a search head will not complete if apps or add-ons included in the ES package are managed by a deployment server. So now it's down to your administrative processes around upgrades and app management. If you want to keep ES SH centrally managed, you'll implement deploymentclient.conf, but include steps in your upgrade docs to pre-prep the ES SH and disable it, and re-enable it after the upgrade completes. You'll have to decide if the "Splunk_TA_ForIndexers" (which is generated AFTER the upgrade of the ES SH) is easier to manage conceptually then just extracting add-ons/TA's from the installer, reviewing the props/transforms for any active ones you care about, staging them on the DS, and deploying them normally. The "Splunk_TA_ForIndexers" is also completely ignorant of volume settings and other customized elements in you indexes.conf. Another resource is your SE or a PS rep, especially if they were involved in the ES SH implementation. Good luck! ... View more

Please note that with the release of Splunk 6.6, there's a feature to find, alert, and manage orphaned knowledge objects. The details are available in the documentation here. As an admin, you'd receive a daily alert, have a dashboard to review the objects, and an opportunity to reassign them to a different user. Reviewing the steps above, the "Orphaned Scheduled Searches, Reports, and Alerts" dashboard and UI to manage objects would replace Steps 2, 3, and 4 for most use-cases. Enjoy! ... View more

Good day. From your comments above, I'm assuming the issue is determining why some forwarders on occasion will not connect to the indexers. There are a lot of potential reasons why an Indexer wouldn't be reachable for a period of time. If the indexer's processing queues are blocked, it could stop accepting new forwarder (agent) connections until the queues clear. The Management Console is used to monitor the queues on the indexers. Here's a link to the configuration docs for the Console. Queues can become blocked for a lot of reasons, including invalid or poor quality props/transforms, slow storage IOPS, and so on. On the Indexers, make sure the Transparent Huge Pages is disabled, check the ulimits, and test the storage (FIO, or Bonnie++) to validate that the Indexers have the best chance of performing consistently. Another common scenario is one forwarder agent getting locked for long periods of time to one Indexer. This is usually due to a single, large data source coming from that forwarder that doesn't line break. As a result, one Indexer will be the recipient of one data source (no distribution.) And that Indexer will not be available to accept data from other forwarders. ... View more

Good news! ... View more

The inputs.conf that creates the UDP listener might live under $SPLUNK_HOME/etc/system/local, or $SPLUNK_HOME/etc/apps/search/local. Remember that you can have multiple inputs.conf files, and that they're all merged to set the active configuration on the forwarder. If you want to determine where that inputs.conf file is using the CLI, leverage the BTOOL command ./splunk cmd btool inputs list --debug and look for your UDP stanzas. The debug portion of the tool command ensures that the file paths are shown. Yes, get used to editing the .conf files directly in a text editor, as there are options available that are not exposed in the UI. ... View more

There's a chance you're running into SOLNESS-12077. The search that reports on threat source download failures will always show any past failures logged, and will not reflect more recent threat downloads that were successful. That issue was fixed in ES 4.7.2. ... View more

How do we allow individual business units to only access data related to their environment when they log in to the system? The Roles in Splunk can allow access to a few, or many indexes. Isolating data sources based upon data center, business unit, or other categories will be easy at the beginning, but will become complex as the environment grows and changes. In general, the best idea is to aggregate similar data sources into a single index, unless your internal security/data access restrictions will absolutely not allow it. As to restricting searchable data, Role-based search filters are easy to implement, provide the ability to obscure data, can slow down searching if there complex or many inherited filters, and are not tough to work around if determined. They might not be secure enough for your use-case. I understand Splunk bases its permissions on indexes, however does this get complicated due to the fact that Enterprise Security has already created three Windows-associated indexes for itself (perfmon, windows, wineventlog)? By default, ES doesn't create Windows indexes (see here) so those have probably been created by the Windows Add-on/TA. ES isn't pre-configured to look for, or need specific index names to function. ES needs access to all indexes that have security-applicable data, the data has to be CIM compliant (configured through the appropriate add-on/TA,) and it has to have enough resources (cores, I/O, and storage) to maintain the Data Model Accelerations. As a result, you can have many, few, or one index with Windows data. As long as the ES Roles have access, the Add-on is installed, and the Data Model Accelerations are working, the Windows data will be searched by the ES app. I think that covers the core of your question, but feel free to as a follow up if I've missed the point. ... View more

Generally speaking, the reason to have multiple Indexers is to address a scenario where one Indexer (for some reason) isn't accepting connections. If the queues are blocked, the Indexer will stop accepting connections. The Forwarder's will cycle though to the next Indexer in the list, as defined in outputs.conf. That's your #2. The only time I've run into your #1 scenario is if a Forwarder or Indexer is forwarding data to a 3rd party, that 3rd party system stops accepting connections, and the outputs.conf settings such as dropEventsOnQueueFull are configured to allow a drop. ... View more

Good day. Are you saying the Deployment Server cannot connect to the Indexer(s)? The port in your example above "9997" is the defacto port for communication outbound from a forwarder to the Indexers. In that case, I would check the network paths between the Deployment Server and the Indexers. I would also check if the "Connection to Host" list represents some, or all of your Indexers. A telnet session from the DS to the Indexer listener port (9997) is an easy check. Are you saying that Forwarders (agents) cannot connect to the Deployment Server? A Deployment Server accepts connections from Forwarders on the Management Port (8089.) In that case, I would check the network paths between the Forwarders and the Deployment Server. The network should allow inbound to the DS on port 8089. Also review the deploymentclient.conf on your Forwarders, and check that the correct IP and Port are being used. The Forwarder Management UI on the Deployment Server will display the host names from any Forwarders that have checked in. ... View more

For ES 4.6 and later, the REST endpoint to call has changed. Sample from the ES admin docs: | rest splunk_server=local count=0 /services/saved/searches | where match('action.correlationsearch.enabled', "1|[Tt]|[Tt][Rr][Uu][Ee]") | rename eai:acl.app as app, title as csearch_name, action.correlationsearch.label as csearch_label, action.notable.param.security_domain as security_domain | table csearch_name, csearch_label, app, security_domain, description ... View more