Can you disable the management port (8089) on clients via the Deployment Server?

[asofo]

We're looking to disable the management port (8089) on current and future clients. Can this be done from a policy or setting on the Deployment server?

[ephemeric]

I think the OP wants to secure the UFs.

By default the UF binds `*:8089` which is an audit finding in most envs.

To be sure, configure /opt/splunkforwarder/etc/splunk-launch.conf:

SPLUNK_BINDIP=127.0.0.1

[jtacy · Accepted solution]

Yes, you can deploy an app with a server.conf like this:

# Disable management port to prevent remote (or local) config.
[httpServer]
disableDefaultPort = true

We deploy our UFs with an app like this and the port is not even open on the client with it installed. It doesn't break the deployment client functionality either. Good luck!

[CarolinaHB]

Hello, @jtacy . 

A question, Is the file being changed from the C:\Program Files\SplunkUniversalForwarder\etc\system\local\”?

Thank very much.

Regards.

[mustapha_arakji]

Hi @CarolinaHB ,

While that's true, changing the server.conf in C:\Program Files\SplunkUniversalForwarder\etc\system\local\ will give you the desired results. It's a best practice to place the server.conf file in a separate app as @jtacy said. That would be in $SPLUNK_HOME/etc/apps/myapp/local/server.conf.

Recommended read on config files:

https://docs.splunk.com/Documentation/Splunk/9.1.3/Admin/Wheretofindtheconfigurationfiles

HTH

[mustapha_arakji]

Snippet from Splunk docs about changing server.conf file:

https://docs.splunk.com/Documentation/Splunk/9.0.0/admin/Serverconf

disableDefaultPort = <boolean>
* If set to "true", turns off listening on the splunkd management port,
  which is 8089 by default.
* On Universal Forwarders, when  this value is "true" the value set 
  for mgmtHostPort in web.conf will be ignored. Similarly, when set to "false", 
  the value set for mgmtHostPort in web.conf will be used for binding management port.
* NOTE: On Universal Forwarders, to reduce the risk of exploitation Splunk recommends 
  the management port is disabled and local CLI is not used. If the management port is enabled, 
  a valid TLS certification should be installed and the port should be bound to localhost.
* NOTE: Changing this setting is not recommended on other Splunk instances.
  * This is the general communication path to splunkd.  If it is disabled,
    there is no way to communicate with a running splunk instance.
  * This means many command line splunk invocations cannot function,
    Splunk Web cannot function, the REST interface cannot function, etc.
  * If you choose to disable the port anyway, understand that you are
    selecting reduced Splunk functionality.
* Default: false

[woodcock]

How can it not "break" the DS functionality? If you change this to "false" on the DS, because the DC is not connecting (port is disabled), it will never get updated. You will have to login to the DC servers and manually change this (after changing it on the DS) in order for it to start working again.

[dshpritz]

keep in mind that the DS does not "push". Clients connect to it, and pull their configuration. The DS does not talk to the UF management port.

[jtacy]

Howdy, I'm reading the question as asking about disabling the mgmt port on deployment clients (most likely UFs). You're right that it's important to be aware that the DS itself must listen on the mgmt port or you're sure to break things.

[woodcock]

Why are you doing this? I assume it is so that you can prevent some app (all apps?) from being updated by the Deployment Server. The best way to do this is to disable DS client updates for just the app you need to "freeze" on just this server (not server-wide, not app-wide, not globally); you can do this like this (and yes, this can be done from the DS, but if you do this, it will disable this app on all servers and it cannot be undone from the DS):

$SPLUNK_HOME/etc/apps/MyApp/default/app.conf:
[install]
allows_disable = false

The first thing the DS Client does whenever it finds that the app does not match the DS master copy is to disable the app so that nobody can use it while it is being updated. If DS cannot disable the app, then it also cannot update it, so DS will be deadlocked from changing the app. If you forget to undo your changes, then whatever portion you disabled will never update. It is better to have just 1 app DS-disconnected than to have your entire node completely DS-orphaned.

[laserval]

I believe the question is referring to disabling the management port on e,g. forwarders. The deployment clients are the ones sending requests to the deployment server - they don't need to have any open management port unless you want to do stuff like remotely run oneshot inputs.

[asofo]

Correct. I should have clarified this is simply for the forwarders. We do not plan to remotely manage them through the management web interface (remote management disabled by default anyway) and want to close any unnecessary ports for security reasons.

[woodcock]

Then the OP should have said "disable the remote management web interface", not "disable the port". There are 2 things that happen on that port: DS and Web UI. I gave one answer and jtacy gave the other. In any case, the "disableDefaultPort" approach WILL NOT prevent port 8089 from being used if you are using DS because your DC on the forwarder will still us it.