We are sending RSA secureid logs to syslog then using a Universal Forwarder to send to a Heavy Forwarder which then sends everything to Splunk Cloud. All that works fine except for the host name in splunk if using the standard inputs.conf entry of
host_segment=x because the file produced by rsa is todays' date ex: 2018-01-22 so that becomes the host.
I have looked at doing regex extractions, but there are two ip's side by side and the regex returns extra garbage as well. I removed the host_segment component by everything now has the Universal Forwarder name as the host (which it should). I followed this link: https://answers.splunk.com/answers/425848/how-to-set-host-from-an-extracted-field.html and still get only the UF as the host so I'm looking for some help from the community. A sample of the log file:
Jan 22 18:42:30 2018-01-22 18: 42:30,628, , audit.runtime.com.rsa.ims.authn.impl.AuthenticationBrokerImpl, INFO, e557de7144271b0a1923ceae96e5d594,eb5901ed44271b0a08022c8910d01e29,10.27.39.70,10.27.39.68,AUTHN_LOGIN_EVENT,13002,SUCCESS,AUTHN_METHOD_SUCCESS,e51fd3fb44271b0a19221f45f6896695-TBO8ACj0TWh7,0b3e94e944271b0a1b44c6d742dc0057,6e14e43644271b0a1b1d3a065fe5da7f,000000000000000000001000e0011000,aegariba,Ashley,Garibaldi,3bcfac6e44271b0a1ba38a9b14338de7,000000000000000000001000e0011000,10.27.39.70,tcblap13.ad.texaschildrenshospital.org,7,000000000000000000002000f1022000,SecurID_Native,,,AUTHN_LOGIN_EVENT,5,1,,,,,55dc625944271b0a1994cfc708171ab3,xxxxxxx16440
Jan 22 18:43:53 2018-01-22 18: 43:53,647, , audit.admin.com.rsa.authmgr.internal.admin.principalmgt.impl.AMPrincipalAdministrationImpl, INFO, 39a2797444271b0a1a7aa7418ac85efa,eb5901ed44271b0a08022c8910d01e29,,10.27.39.68,UPDATE_AM_PRINCIPAL,20002,SUCCESS,,,,,,,,,,PRINCIPAL,d8e2bab244271b0a1c2f73c87092dd83,6e14e43644271b0a1b1d3a065fe5da7f,000000000000000000001000e0011000,rmvadala,,,,,,
Sometime the second IP can also be a FQDN entry, not often but every so often its there the second entry is missing the calling_ip hence the ,,10.27.39.68 (it is not always this IP, that would be too easy).
For the transforms this is what is in play:
[rsa_securid_runtime_syslog_extract_field_0] FIELDS = "syslog_header", "milliseconds", "unused21", "logger_name", "log_level", "unused22", "unused23", "client_ip", "server_ip", "vendor_event_type", "unused24", "vendor_action", "vendor_action_description", "session_id", "actor_guid", "unused27", "unused28", "user_name", "user_first_name", "user_last_name", "agent_guid", "unused210", "agent_ip", "agent_name", "agent_type", "unused214", "authentication_type", "unused215", "authentication_description","argument1","argument2","argument3","argument4","argument5","argument6","argument7","argument8","argument9","argument10" DELIMS = ","
[rsa_host_name] SOURCE_KEY = server_ip (This is created in a FIELDS extraction above) REGEX = (.*) DEST_KEY = MetaData:Host
Only Local; [rsa:secureid:system:syslog] TRANSFORMS-rsahost = rsa_host_name [rsa:secureid:admin:syslog] TRANSFORMS-rsahost = rsa_host_name [rsa:secureid:runtime:syslog] TRANSFORMS-rsahost = rsa_host_name
The default props uses the same field server_ip for CIM renames:
FIELDALIAS-dest = server_ip as dest FIELDALIAS-dvc = server_ip as dvc
Everything looks good in Btool
On start-up receive this:
Undocumented key used in transforms.conf;
stanza='rsa_host_name' setting='SOURCE_KEY' key='server_ip'
Based upon the error it doesn't like SOURCE_KEY
What values should I be using so I can use server_ip as my host name?
Thanks in advance!
Thank yo, this worked fine for eliminating the error I was having. In re-reading the transforms.conf.spec documentation I saw where it said to use field: or fields: Further reading showed me the errors of my ways. I was trying to do this as a index time not a search time replacement. Fields can only be used for search time modifications. This is a cloud search head so now trying to figure out how to make it work there as you don't have access to the cli to to transforms. The Gui does have some capabilities, but I'm not seeing it for host replacement. Your answer was correct, again thank you!