I am having issues with the Bluecoat TA in my environment. I am trying this on our Dev environment before I send to our Production environment.
I have followed the installation steps mentioned in the TA (https://docs.splunk.com/Documentation/AddOns/released/BlueCoatProxySG/Configureinputs) and I am running SPLUNK v 7.2.6 with version 3.5.0 of the TA. The Bluecoat has been configured to send logs using the standard bcreportermainv1 log and configured as W3C and ELFF and is a stream.
SPLUNK has had a TCP data input created with the port set as TCP/514 and the sourcetype configured as
"bluecoat:proxysg:access:syslog" and in my test environment a new index called `"bluecoatdev"`.
Once configured I can verify that I am receiving logs. The logs look the way I expect, but SPLUNK effectively has this as 1 liner and not using the TA to extract the data into the required fields.
If I search by the index it shows the above information but if I search by the sourcetype I receive "0 results" which definitely indicates that SPLUNK is not recognizing or using the sourcetype.
Would appreciate any insight into where this might be going wrong.
I have 2 proxies that I am sending data from
** Older proxy (version 6.5) index shows:
source = tcp:5156
sourcetype = bluecoat:proxysg:access:syslog
linecount = 1
Event is \x81\xFAn/XeFu...........\xF7x\xBF.......
** New proxy (version 6.7)
source = tcp.bluecoat (note ".") - this sources contains 99% of the count !!! it also shows another source being tcp:514 (note ":")
eventtype = bluecoat_proxy (100% of count) !!! also has another eventtype of err0r (12%)
linecount = 1
Event shows as per bcreportermain_v1. For example (substituted IP and URI)
2019-06-21 03:55:42 6111 192.168.1.10 - - - google.com 184.108.40.206 None - - OBSERVED "Technology" - 0 TUNNELED unknown - ssl google.com 443 / - - - 192.168.1.10 1234 - "none" "none" "none" 3 83498934897938-490363908603ee2985-4290498092406ef4 - - 220.127.116.11 google.com
This particular logs shows source = tcp.bluecoat and sourcetype=bluecoat:proxysg:access:syslog. If I do a search with just the sourcetype of source then I get "No results found"
Try running the following command in the CLI. It will show you what configs are being applied to that specific input and might show if a different sourcetype is being applied first based on precedence order.
splunk btool inputs list TCP/514 --debug
Whatever goes after list just needs to identify your input stanza, so try anything that's part of it. If it still doesn't work just try it without that parameter, you just have to dig through through all the input configurations. (both examples below)
splunk btool inputs list anythingthatispartoftheinput_stanza --debug
splunk btool inputs list --debug
Have you installed the TA on the indexer to define the source type for the input on the receiving end ?
Make sure your input on port 5156 is configured with the right sourcetype and the index time configuration for that sourcetype is on the indexer. If you don't know what to put on the indexer then you can start by installing the entire TA there for the props/transforms configuration.
The instance I am sending my data to is an all in one single deployment (this is my test environment). I have the entire TA installed. In fact I went through and removed the old version and removed the app from my instance. I then reinstalled the most recent version for the Bluecoat TA.
Hi @willadams ,
My experience with Bluecoat Proxy SG data is that the data and underlying format of the data seems to change frequently after Bluecoat makes a code change. This makes it hard to track down what settings to use for your Bluecoat devices, and even harder if you're running different versions of the software.
In your case however, it appears that the TA is not updated enough to accommodate your new proxy. The TA only supports up to version 6.6.x, and you're running v6.7.
You'll need to read through the Admin manual for v6.7 to determine the fields, and then create a new props.conf & transforms.conf REPORT to extract those fields. You can use the existing v6.5 & v6.6.x REPORT settings as a guideline.
If you're not familiar with doing this kind of work, consider reaching out to Splunk to see if they have an Admin-on-demand or Professional Services solution that meets your needs. This is probably about a day or two of work from a Professional Services perspective.