<?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: Reduce specific logging in Installation</title>
    <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288584#M7689</link>
    <description>&lt;P&gt;Why don't you manually &lt;CODE&gt;null-route&lt;/CODE&gt; the attacking host's IP on the attacked device so it can no longer attempt to connect?  Then the failed logins do not happen.  For that matter, why is this kind of mitigation not automatically in place in your network (e.g. &lt;CODE&gt;fail2ban&lt;/CODE&gt; or whatever)? Remove it when the proper configuration is in place.&lt;/P&gt;

&lt;P&gt;&lt;A href="https://en.wikipedia.org/wiki/Null_route"&gt;https://en.wikipedia.org/wiki/Null_route&lt;/A&gt;&lt;BR /&gt;
P.S.  I know that this is not an "attack".&lt;/P&gt;</description>
    <pubDate>Tue, 04 Jul 2017 15:12:34 GMT</pubDate>
    <dc:creator>woodcock</dc:creator>
    <dc:date>2017-07-04T15:12:34Z</dc:date>
    <item>
      <title>Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288580#M7685</link>
      <description>&lt;P&gt;When there's a huge influx of incoming logging of blocked attempts on the firewall from one specific (external) source, is it possible to (temporarily) decrease/disable the amount of logging being received from this specific source so it doesn't flood our license when it's a known issue? &lt;/P&gt;

&lt;P&gt;Thanks in advance for the response&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2017 09:42:38 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288580#M7685</guid>
      <dc:creator>mmoermans</dc:creator>
      <dc:date>2017-07-04T09:42:38Z</dc:date>
    </item>
    <item>
      <title>Re: Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288581#M7686</link>
      <description>&lt;P&gt;Hi mmoermans,&lt;BR /&gt;
it's possible to create a filter but the problem is that you have to restart Splunk to enable it.&lt;BR /&gt;
At this point it's easier to stop log forwarding from your firewall and restart it after the tempest. &lt;BR /&gt;
Bye.&lt;BR /&gt;
Giuseppe&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2017 14:53:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288581#M7686</guid>
      <dc:creator>gcusello</dc:creator>
      <dc:date>2017-07-04T14:53:43Z</dc:date>
    </item>
    <item>
      <title>Re: Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288582#M7687</link>
      <description>&lt;P&gt;hello there, &lt;BR /&gt;
i am not aware of anything "out of the box" that splunk has for that situation, if there is, would love to learn about it. &lt;BR /&gt;
With that being said, one thing i can think of is setting an alert on your condition,&lt;BR /&gt;
add trigger a script to that alert and have the script writing props and transforms that sending the unwanted data to nullqueue. Challenge here is how you reset back to your original configurations. maybe the script will also have a timer to reset after X amount of time.&lt;BR /&gt;
there are other challenges with that approach, specially if this is a clustered environment.&lt;BR /&gt;
hope it slightly helps&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2017 15:03:09 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288582#M7687</guid>
      <dc:creator>adonio</dc:creator>
      <dc:date>2017-07-04T15:03:09Z</dc:date>
    </item>
    <item>
      <title>Re: Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288583#M7688</link>
      <description>&lt;P&gt;The only practical way is to stop splunk on that forwarder (host).&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2017 15:08:54 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288583#M7688</guid>
      <dc:creator>woodcock</dc:creator>
      <dc:date>2017-07-04T15:08:54Z</dc:date>
    </item>
    <item>
      <title>Re: Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288584#M7689</link>
      <description>&lt;P&gt;Why don't you manually &lt;CODE&gt;null-route&lt;/CODE&gt; the attacking host's IP on the attacked device so it can no longer attempt to connect?  Then the failed logins do not happen.  For that matter, why is this kind of mitigation not automatically in place in your network (e.g. &lt;CODE&gt;fail2ban&lt;/CODE&gt; or whatever)? Remove it when the proper configuration is in place.&lt;/P&gt;

&lt;P&gt;&lt;A href="https://en.wikipedia.org/wiki/Null_route"&gt;https://en.wikipedia.org/wiki/Null_route&lt;/A&gt;&lt;BR /&gt;
P.S.  I know that this is not an "attack".&lt;/P&gt;</description>
      <pubDate>Tue, 04 Jul 2017 15:12:34 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288584#M7689</guid>
      <dc:creator>woodcock</dc:creator>
      <dc:date>2017-07-04T15:12:34Z</dc:date>
    </item>
    <item>
      <title>Re: Reduce specific logging</title>
      <link>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288585#M7690</link>
      <description>&lt;P&gt;The&lt;CODE&gt;splunky&lt;/CODE&gt; way to do this now is with &lt;CODE&gt;Phantom&lt;/CODE&gt;-based automation.&lt;/P&gt;</description>
      <pubDate>Fri, 08 Nov 2019 15:10:20 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Installation/Reduce-specific-logging/m-p/288585#M7690</guid>
      <dc:creator>woodcock</dc:creator>
      <dc:date>2019-11-08T15:10:20Z</dc:date>
    </item>
  </channel>
</rss>

