<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Fortigate TA Config Queries in All Apps and Add-ons</title>
    <link>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450412#M55415</link>
    <description>&lt;P&gt;Thanks for the quick response. And thanks again for supporting Splunk (and Splunkers) with your TA. It's greatly appreciated. G.&lt;/P&gt;</description>
    <pubDate>Thu, 21 Mar 2019 03:28:02 GMT</pubDate>
    <dc:creator>gvmorley</dc:creator>
    <dc:date>2019-03-21T03:28:02Z</dc:date>
    <item>
      <title>Fortigate TA Config Queries</title>
      <link>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450410#M55413</link>
      <description>&lt;P&gt;This is one for the folks at Fortigate regarding their TA.&lt;/P&gt;

&lt;P&gt;I had a couple of queries on the latest version (1.6.0), specifically around the &lt;CODE&gt;transforms.conf&lt;/CODE&gt;&lt;/P&gt;

&lt;P&gt;Looking at the &lt;CODE&gt;force_sourcetype_fgt_traffic&lt;/CODE&gt; stanza:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[force_sourcetype_fgt_traffic]
DEST_KEY = MetaData:Sourcetype
REGEX = devid=\"?F[G|W|6K].+type=\"?traffic
FORMAT = sourcetype::fgt_traffic
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I'm 99% sure that you can't do alternation inside a character class. So &lt;CODE&gt;[G|W|6K]&lt;/CODE&gt; actually means any character from the set &lt;CODE&gt;GW6K&lt;/CODE&gt; or the literal &lt;CODE&gt;|&lt;/CODE&gt;.&lt;/P&gt;

&lt;P&gt;Was the intention that it should actually be &lt;CODE&gt;(?:G|W|6K)&lt;/CODE&gt;, which would be a non-capturing group of either &lt;CODE&gt;G&lt;/CODE&gt;, &lt;CODE&gt;W&lt;/CODE&gt; or &lt;CODE&gt;6K&lt;/CODE&gt;?&lt;/P&gt;

&lt;P&gt;Secondly, you might want to reconsider the structure of these a bit. Taking that same stanza as above, it would actually match a &lt;CODE&gt;utm&lt;/CODE&gt; event like this:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;date=2019-03-15  time=05:12:28 logver=52 timestamp=1552626748 tz="UTC+0" devname="example-dev" devid="FG600C9999999999" logid="12345" type="utm" subtype="app-ctrl" eventtype="app-ctrl-all" level="information" vd="root" appid=12345 user="" srcip=10.1.1.1 srcport=64224 srcintf="INTERNAL" dstip=8.8.8.8 dstport=80 dstintf="EXTERNAL" proto=6 service="HTTP" policyid=42 sessionid=158758809 applist="standard" appcat="Web.Others" app="HTTP.BROWSER" action="pass" hostname="test.example.com" url="/net/WebService.aspx?type=traffic&amp;amp;Password=fred8" msg="Web.Others: HTTP.BROWSER," apprisk="medium"
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;It's the first of the &lt;CODE&gt;force&lt;/CODE&gt; transforms tried against &lt;CODE&gt;fgt_log&lt;/CODE&gt;. So even though the event has &lt;CODE&gt;type="utm"&lt;/CODE&gt;, it matches later in the event due to data in the &lt;CODE&gt;url&lt;/CODE&gt; field. So the result would be that this event would be &lt;CODE&gt;sourcetype=fgt_traffic&lt;/CODE&gt;. Now, as the remaining &lt;CODE&gt;force&lt;/CODE&gt; transforms continue to be applied, it would probably then match the &lt;CODE&gt;force_utm&lt;/CODE&gt; one later and then get set to that. &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;  But it would probably be better to get it set correctly once.&lt;/P&gt;

&lt;P&gt;One approach might be to combine your 3 &lt;CODE&gt;force&lt;/CODE&gt; stanzas into one. So look to do this:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;default/props.conf
[fgt_log]
TRANSFORMS-force_sourcetype_fgt = force_sourcetype_fgt

default/transforms.conf
[force_sourcetype_fgt]
SOURCE_KEY = _raw
DEST_KEY = MetaData:Sourcetype
REGEX = devid=\"?F(?:G|W|6K).+type="?(traffic|utm|event)
FORMAT = sourcetype::fgt_$1
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;You also get the advantage that Splunk only has to try the one stanza / regex per event, as opposed to three.&lt;/P&gt;

&lt;P&gt;Finally, although it's a bit beyond the scope here, so may also want to look to anchor the regex and consider some backtracking control.&lt;/P&gt;

&lt;P&gt;This proved more performant for a lot of my testing:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[force_sourcetype_fgt]
SOURCE_KEY = _raw
DEST_KEY = MetaData:Sourcetype
REGEX = ^.+?\sdevid=(*COMMIT)\"?F(?:G|W|6K).+?\stype=(*COMMIT)\"?(traffic|utm|event)
FORMAT = sourcetype::fgt_$1
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;The &lt;CODE&gt;(*COMMIT)&lt;/CODE&gt; is a way of saying, "It you get this far in the match, but fail later, don't backtrack past this".&lt;/P&gt;

&lt;P&gt;So the regex above is saying, "Going from the start of the line ( &lt;CODE&gt;^&lt;/CODE&gt; ), look for any character 1 or more times (lazily). When you find &lt;CODE&gt;devid=&lt;/CODE&gt;, then we know we're in the right place. If our &lt;CODE&gt;F(?:G|W|6K)&lt;/CODE&gt; doesn't match, then &lt;STRONG&gt;don't&lt;/STRONG&gt; go back and try to find it anywhere else. Once we got to &lt;CODE&gt;devid=&lt;/CODE&gt; we were committed - there's no going back now..."&lt;/P&gt;

&lt;P&gt;Basically, it's a handy way to stop the regex being tried later in the event. But I'm not regex guru, so do some testing and see how it works. It just proved useful for us in our environment.&lt;/P&gt;

&lt;P&gt;The main one is really to see if you need to fix-up the alternation in the character class and possibly combine the stanzas in a future TA release.&lt;/P&gt;</description>
      <pubDate>Wed, 20 Mar 2019 08:34:27 GMT</pubDate>
      <guid>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450410#M55413</guid>
      <dc:creator>gvmorley</dc:creator>
      <dc:date>2019-03-20T08:34:27Z</dc:date>
    </item>
    <item>
      <title>Re: Fortigate TA Config Queries</title>
      <link>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450411#M55414</link>
      <description>&lt;P&gt;Hi gvmorley&lt;BR /&gt;
Thanks for pointing out the bug and providing a better approach.&lt;BR /&gt;
We sure will verify it and include the fix in future release.&lt;BR /&gt;
Thanks again!&lt;/P&gt;</description>
      <pubDate>Wed, 20 Mar 2019 18:25:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450411#M55414</guid>
      <dc:creator>jerryzhao</dc:creator>
      <dc:date>2019-03-20T18:25:43Z</dc:date>
    </item>
    <item>
      <title>Re: Fortigate TA Config Queries</title>
      <link>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450412#M55415</link>
      <description>&lt;P&gt;Thanks for the quick response. And thanks again for supporting Splunk (and Splunkers) with your TA. It's greatly appreciated. G.&lt;/P&gt;</description>
      <pubDate>Thu, 21 Mar 2019 03:28:02 GMT</pubDate>
      <guid>https://community.splunk.com/t5/All-Apps-and-Add-ons/Fortigate-TA-Config-Queries/m-p/450412#M55415</guid>
      <dc:creator>gvmorley</dc:creator>
      <dc:date>2019-03-21T03:28:02Z</dc:date>
    </item>
  </channel>
</rss>

